Menu

#1164 Regression with HTTP Digest auth and connection reuse

closed-fixed
http (206)
5
2014-10-21
2012-11-02
Joe Mason
No

As reported by Nick Zitzmann in this email thread: http://curl.haxx.se/mail/lib-2012-10/0120.html

I didn't see this on the list of known bugs. I found a problem today where, if a server advertises support for HTTP Digest authentication and libcurl authenticates with the server successfully, and then re-uses the connection, then the next attempt to fetch something that requires authentication will fail. This does not happen when using HTTP Basic authentication to authenticate with the server.
Specifically, what happens is:
1. The app using libcurl creates a new easy handle and configures it with the URL, authentication information, etc.
2. libcurl opens a connection to the server
3. libcurl sends an HTTP request
4. The server returns HTTP 401 (as expected)
5. libcurl automatically rewinds and sends another request to the URL, this time with an Authorization header (correct behavior)
6. The server returns the requested information
7. The app using libcurl calls curl_easy_perform() again on the same easy handle with a URL pointing to the same server
8. Re-using the connection, libcurl sends an HTTP request, but does not print the Authorization header (oops, that's not expected behavior)
9. The server returns HTTP 401
10. libcurl gives up and returns an authentication error to the app
This used to work as expected in the older version of libcurl that this particular project was using, which was 7.23.1.
After a lot of searching, I finally figured out what caused this regression. It was this commit:
<https://github.com/bagder/curl/commit/ce8311c7e49eca93c136b58efa6763853541ec97>
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

Discussion

  • Joe Mason

    Joe Mason - 2012-11-02

    Forgot to mention in the description that this regression appeared in 7.28.0

     
  • Daniel Stenberg

    Daniel Stenberg - 2012-11-04

    test1412 verifies that repeated Digest auth works (like before)

     
  • Daniel Stenberg

    Daniel Stenberg - 2012-11-04

    I've attached test1412 that shows the problem. This works if ce8311c7e49ec is reverted.

    However if we revert that commit, test 2024 breaks instead...

     
  • Joe Mason

    Joe Mason - 2012-11-04

    > Is this the same problem as bug #3577557 ?

    Depends on what you mean by "same". It has the same root cause, but it seems to be a different function that was broken by ce8311c7e49ec. This bug is about Digest auth not working for GET requests if more than one auth type is allowed in CURLOPT_HTTPAUTH. #3577557 is about auth being broken for PUT requests.

    Dunno if you want to track each symptom in a separate bug, or just one bug for all the stuff broken by ce8311c7e49ec

     
  • Daniel Stenberg

    Daniel Stenberg - 2012-11-04

    My plan right now is to do that revert and see what I can do on the test 2024.

     
  • Daniel Stenberg

    Daniel Stenberg - 2012-11-06

    Thanks for the report, this problem is now fixed in the git repository.

    To try it out, you either checkout/update your git clone: http://curl.haxx.se/source.html

    or you try tomorrow's daily snapshot: http://curl.haxx.se/snapshots/

     
  • Daniel Stenberg

    Daniel Stenberg - 2012-11-06
    • status: open --> closed-fixed
     
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.