bug#62598: 29.0.60; url-https-proxy-connect doesn't support multi-stage auth to proxies

[Thomas Fitzsimmons <fitzsim@fitzsim.org>]

Hi Spencer,

Spencer Baugh <sbaugh@janestreet.com> writes:

> url-http knows how to use HTTPS proxies, primarily in
> url-https-proxy-connect.  It even knows to authenticate to those
> proxies, as fixed in bug#42422.
>
> But some HTTP authentication methods (e.g. NTLM as supported by
> url-http-ntlm) require multiple stages of back-and-forth in
> authentication.  This works fine with regular HTTP requests and requests
> to HTTP (non-S) proxies; it's handled by url-http-handle-authentication
> which is called by url-http-parse-headers when it sees a 401 or 407
> (auth required and proxy auth required) status.
>
> But this does not work with the HTTPS proxy support, because if it sees
> 401 or 407 as a response to CONNECT, it just immediately fails.

Why can't that code path call url-http-handle-authentication instead of
just failing?  What makes HTTPS different from HTTP in this respect?

> I'm very interested in adding this but I'm unsure how to approach it.  I
> guess that url-https-proxy-after-change-function should be calling
> something similar to url-http-handle-authentication.  Or maybe the whole
> design of how HTTPS proxy support works today is wrong, and it should be
> calling url-http-parse-headers like everything else?

I'd say try to make both approaches work, and see which one results in
the minimum set of changes.

Thomas