Re: HTTPS Proxy Support

Rodrigo Arias wrote:
> On Wed, Jun 26, 2024 at 08:52:37AM +1000, Kevin Koster wrote:
>>Rodrigo Arias <rodarima-Re5JQEeQqe8AvxtiuMwx3w-XMD5yJDbdMReXY1tMh2IBg-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.
_______________________________________________
Dillo-dev mailing list -- dillo-dev-lx9mn2B4QYRWk0Htik3J/[email protected]
To unsubscribe send an email to dillo-dev-leave-lx9mn2B4QYRWk0Htik3J/[email protected]