Rodrigo Arias wrote:
On Wed, Jun 26, 2024 at 08:52:37AM +1000, Kevin Koster wrote:
Rodrigo Arias <rodarima-Re5JQEeQqe8AvxtiuMwx3w-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org> wrote: 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.
Yes that sounds like a good way to bring Dillo into line with other software, and also means that the environment variables apply consistently to downloads since they use Wget.
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.
Affected users would have already been seeing inconsistent behaviour with file downloads since Wget is already using https_proxy.
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.
Yep, and obviously in the changelog too, to be better than Wget and its undocumented past switch to tunneling HTTPS connections through 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.
Yes I agree.
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.
That would be fine.
Lastly, a similar option was mentioned by Daniel (curl lead developer) some time ago: https://stackoverflow.com/a/34268925
It doesn't appear that anyone implemented it in Curl though.