A user of rustup came to us yesterday with an issue they have. Their corporate web proxy runs on port 80, not port 8080 and they cannot use rustup via our env_proxy support (forcing them to fall back to cURL mode).
As an example, I wrote a trivial echo-proxy program:
This means that if a URL has an explicit :PORTNR where that matches the default port number for the scheme in question (http and :80 here) then it claims the incoming URL had no port number. As such your approach to detecting the port is not going to always work.
As I see it there are two options here:
An alternative, more explicitly preserving-of-form URL parser is used
A change to url is proposed in which the port (if present) is always recorded, and then perhaps not serialised back out if it's not needed.
Either way, right now this is blocking some rustup users from being able to use env_proxy and reqwest because of their corporate proxies using port 80 :(
The text was updated successfully, but these errors were encountered:
@kinnison Nice analysis. While running a proxy on port 80 is... eccentric, it should be supported. The root of the problem is that a proxy URL uses the http scheme, but its default port is 1080 (cURL) or 8080 (env_proxy), instead of 80, and there is no way to tell that to Url::parse(). I know how I'd change url, and I'll propose the change by and by, but meanwhile I believe that I can patch env_proxy to sidestep the problem.
Okay, running that through my echo proxy test confirms that it works.
I am uncomfortable with the use of unsafe and while I understand the efficiency argument, I wonder if it might be better to have ProxyUrl carry an Option<String> for the scheme which should be used, and then unconditionally replace the scheme in the stored URL when it's set into ProxyUrl ? If you have a better discussion ongoing with url's upstream then ignore me :D
If you can make a release in which this functionality (in whatever form) is present, I'll udpate rustup for it.