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

Previous Next

Full log

Message #8 received at 62598 <at> debbugs.gnu.org (full text, mbox):

From: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 62598 <at> debbugs.gnu.org
Subject: Re: 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

Hi Spencer,

Spencer Baugh <sbaugh <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.