fix: tolerate proxy-injected HTTP responses in aka.ms redirect handling #649
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The dotnet install scripts previously assumed every non-final HTTP status in the aka.ms redirect chain must be 301. Some proxies inject additional HTTP response blocks such as "200 Connection Established", which caused valid redirect chains to be treated as broken. This change: - In Bash: find the last terminal HTTP status (2xx/4xx/5xx), consider only codes before that as the redirect chain, and trim trailing 1xx/2xx entries from it (proxy markers). Then assert all remaining redirect codes are 301. - In PowerShell: apply the equivalent logic inside Get-AkaMSDownloadLink. Includes tests/harnesses for local verification and comments explaining the reason for trimming proxy-injected statuses. Fixes: related discussion in actions/setup-dotnet#650
Author
|
@dotnet-policy-service agree |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The dotnet install scripts previously assumed every non-final HTTP status in the aka.ms redirect chain must be 301. Some proxies inject additional HTTP response blocks, such as "200 Connection Established", which caused valid redirect chains to be treated as broken.
This change:
Includes tests/harnesses for local verification and comments explaining the reason for trimming proxy-injected statuses.
Fixes: related issue in actions/setup-dotnet#650
Summary
Some proxy appliances (e.g. Zscaler) inject HTTP responses into the header
stream (for example,
HTTP/1.1 200 Connection Established) during TLS CONNECTor other proxy operations. The install scripts previously treated any
non-final status in the header stream that is not
301as a broken redirectchain, which incorrectly flagged valid redirects as broken.
This PR makes the aka.ms redirect detection robust by:
301(unchanged semantics).The change is implemented in:
externals/install-dotnet.sh(Bash)dotnet-install.ps1(PowerShell)Why
This fixes cases where a successful redirect chain would be incorrectly
treated as broken when proxies inject connection-establishment responses.
Files changed
externals/install-dotnet.sh— updateget_download_link_from_aka_ms()redirect parsingdotnet-install.ps1— updateGet-AkaMSDownloadLink()redirect parsing