> From: curl-library [curl-library-bounces_at_cool.haxx.se] on behalf of Nick
> Zitzmann [nick_at_chronosnet.com]
>
> 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
Received on 2012-10-15