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.
# 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. 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. 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.