[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#62598: 29.0.60; url-https-proxy-connect doesn't support multi-stage
From: |
Thomas Fitzsimmons |
Subject: |
bug#62598: 29.0.60; url-https-proxy-connect doesn't support multi-stage auth to proxies |
Date: |
Wed, 05 Apr 2023 19:34:21 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
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