> From: curl-library [[email protected]] on behalf of Nick 
> Zitzmann [[email protected]]
>
> After a lot of searching, I finally figured out what caused ncthis 
> regression. 
> It was this commit:
> <https://github.com/bagder/curl/commit/ce8311c7e49eca93c136b58efa6763853541ec97>

I just discovered this myself, and I'm working on a test case.

> The code in that commit zeros out the authentication state in 
> Curl_pretransfer(), which means if we knew that the server wanted digest 
> authorization in the past, we sure didn't anymore. If I comment out that code,
>  then the regression goes away, so I was wondering:
> 
> 1. Why do we do this?

It's possible for a server to be set up with several auth types, using 
different usernames and passwords for each. For example, Basic and Digest auth 
use different formats for their password files, and although most servers keep 
them in sync so that a logical user only has one set of credentials, it's not 
required. So it should be possible to try to connect using Digest, and then if 
the authorization is rejected, try again using Basic. But saving the auth state 
between requests defeats this - once you use CURLAUTH_DIGEST | CURLAUTH_BASIC, 
and it chooses Digest, if you send another request using only CURLAUTH_BASIC, 
it will use Digest again anyway.

(That's a pretty contrived corner case. The actual case that I ran into which I 
needed fixed was using GSS-Negotiate, which requires a lot of extra client-side 
setup to store tickets retrieved from a separate KDC server, and wanting to 
retry using NTLM if the client-side ticket setup was incorrect or the KDC was 
not responding, which is more reasonable.)

> 2. Can we take this out, or can we change this so the zeroing out only happens
>  the first time that particular server/user name/password combination is used?
>  As it is, it is breaking connection re-use and digest authentication. (And 
> apps using libcurl should be able to re-use connections with Digest 
> authentication.)

Off the top of my head, instead of zeroing auth->picked, maybe we should AND it 
with auth->wanted, so that it only gets zeroed if the formerly picked auth is 
no longer specified.

Joe
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

Reply via email to