Hi, On Wed, Jun 26, 2024 at 08:52:37AM +1000, Kevin Koster wrote:
Rodrigo Arias <rodarima-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Also I don't think that 'https_endpoint' actually needs to be set from an environment variable, just a dillorc setting would do.
I also think is good if it is only a dillorc option. I'm not sure if I like more something like:
https_proxy=http://localhost:1234
Ahh, that's what I was doing wrong with Lynx! I didn't include the "http://" part (which Wget doesn't require, though I see now that the Wget manual does say it should be set to a URL, not a hostname). I really do make a meal of this proxy stuff.
Yeah, it is a bit confusing :-)
# Setting this to TRUE sends HTTPS traffic unencrypted to the proxy. # Don't change unless you know what you are doing. #https_proxy_use_http=FALSE (default) https_proxy_use_http=TRUE
For normal uses, setting the https proxy with https_proxy would make more sense than using http_proxy for HTTPS traffic anyway.
If the 'http_proxy' behaviour changes to only apply to HTTP like in other software, everyone using the 'http_proxy' setting will have to change their configuration to set 'https_proxy' as well. That'd be an annoying behaviour change.
But otherwise using the setting name 'https_proxy' makes it unclear how that relates to the 'http_proxy' setting that applies to both HTTP and HTTPS.
Sadly, there is no standard (AFAIK) that specifies how to use those variables, but most software tools seem to use them in a more or less coherent way. And I think new users would expect it to follow the same usage than curl, wget or other browsers. It doesn't have to be annoying, we can slowly deprecate the current mechanism by displaying a warning when only http_proxy is set that https_proxy should be set too, and change the behavior in a new release that is clearly documented in the release notes.
If I set:
http_proxy=http://localhost:1234 https_proxy=http://localhost:5678
It at least needs a comment explaining the difference between the settings, if indeed you intend there to be one and the second setting doesn't override the first entirely.
Since the 'http_proxy' environment variable overrides the dillorc 'http_proxy' setting, 'https_proxy' implies that the same will apply to that, and it's anyone's guess which will apply if both are set since other software (Wget, Lynx) doesn't apply the 'http_proxy' environment variable to https.
Exactly, I think the logical behavior makes sense. Having both http_proxy and https_proxy as environment variables *and* dillorc options. Each controlling the HTTP and HTTPS proxy independently. The same in the future for ftp_proxy to route FTP traffic.
This is why I now think it best to avoid the 'https_proxy' name, because the behaviour with it will never be consistent with other software without changing how Dillo already handles the 'http_proxy' variable/setting.
I undertand, but I think this is a good moment to plan how to change how Dillo handles the http_proxy variable, so it only affects HTTP traffic and not HTTPS too. What about this: Setting the env vars as: http_proxy=http://localhost:1234 https_proxy= Now causes a warning (maybe also in the UI): $ dillo https://www.google.com WARNING: Setting http_proxy to specify the HTTPS proxy is deprecated, use https_proxy to define it instead. But still makes Dillo use the http_proxy both for HTTP and HTTPS for now. Also: http_proxy=http://localhost:1234 https_proxy=http://localhost:1235 No warning: $ dillo https://www.google.com But Dillo uses both proxies independently (like curl or wget), instead of the current implementation that would use http_proxy for HTTP and HTTPS. Same with the dillorc options http_proxy and https_proxy (new), keeping the preference for the env vars if defined. The only unexpected change may be for a user that had previously set https_proxy that was not being used by Dillo, and now it would be. But I think that 1) is unlikely they use a different value for HTTP and HTTPS and 2) it is probably intended to use the https_proxy for HTTPS anyway. We could emit a warning about this too, but maybe not needed if we explain that Dillo will handle now the https_proxy variable. In any case, this should be properly explained in the release notes, leaving one release with the deprecation warning for users to take time to change the behavior, before we stop using http_proxy as the HTTPS proxy. I think this has the benefit of being the implementation most users would expect, as it is consisten with other tools, while having the least amount of pain for current users of proxies as they would have time to realize the deprecation notice. That would allow you to specify *only* the https_proxy like this: http_proxy= https_proxy=http://localhost:1235 $ dillo https://www.google.com No warning and Dillo uses https_proxy for HTTPS and HTTP doesn't use a proxy. And over this change, you can add your specific option in dillorc only to change the way Dillo communicates with the HTTPS proxy to avoid the CONNECT, with the "https_proxy_use_http=TRUE" or similar option. Lastly, a similar option was mentioned by Daniel (curl lead developer) some time ago: https://stackoverflow.com/a/34268925 Best, Rodrigo