Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

update parsing for manually configured proxy on Windows #103328

Merged
merged 1 commit into from
Jun 27, 2024
Merged

Conversation

wfurt
Copy link
Member

@wfurt wfurt commented Jun 12, 2024

Fixes #38670
Fixes #91045

The current behavior was intruded by dotnet/corefx#40082 to support multiple proxies.
The logic for parsing PAC files was also applied to the manual proxy setting.
But as the issues above noticed that does not quite reflect reality.
The existing code assumes that ion the proxy location starts with http:// it would apply only to HTTP (and not HTTPS traffic. In reality one can put http://x.y.x/ string to the proxy location and all browsers would apply it to both http & https.
If the string is prefixed with http= it is also respected e.g. http=http://x.y.x/ would apply only for HTTP and not HTTPS traffic.

To limit regressions I split the logic and tests and I left PAC processing ASIS and I made small change to relax the restrictions if it comes from the manual settings location.

Copy link
Member

@MihaZupan MihaZupan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.
I take it automatic proxy discovery does want something like http=https://proxy.secure.com to only apply to https traffic? Or was that what you meant by trying to limit regressions and not modifying that part?

@wfurt
Copy link
Member Author

wfurt commented Jun 25, 2024

The http= and https= is somewhat easy. The prefix specifies what traffic kind (e.g. http or https) the settings applies to and what URI to go to e.g. you can have http=:http://1.2.3.4:3128, https=http://1.2.3.4:3128 and that would apply proxy to both http & https using some good old plain HTTP proxy (TLS via CONNECT). Things get more shady when the prefix is omitted. The old code assumed that the if the proxy destination is http://x.x.x..x it would apply only to plain HTTP. (I don't know if Windows support secure proxies but I could imagine something like http=https://x.y.z/ but the syntax without)
But that assumption does not work for the manual proxy configuration. I did not do extensive research on the PAC options but too limit risk I left the existing code as is e.g. unless I missed something the PAC should be processed exactly as it is today.

@wfurt wfurt merged commit 8c6e32c into dotnet:main Jun 27, 2024
81 of 83 checks passed
@github-actions github-actions bot locked and limited conversation to collaborators Jul 28, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
2 participants