I sent this on Monday, but nobody's responded - I checked the list archives and I don't see it. Trying again. ________________________________________ From: Joe Mason Sent: Monday, April 16, 2012 10:20 AM To: libcurl development Subject: RE: extra requests sent when using HTTPAUTH_DIGEST
Yeah, I realized while rereading my message that of course curl has no way to associate the data from the WWW-Authenticate header with the username/password I set, so of course it needs to send out a request without any Authorization header first in order to gather that data again. The problem is I want to only pop open a username/password dialog for the user if the server is actually requesting authentication, so I need to wait for the first WWW-Authenticate. And then having to send a second request is wasteful. >From my point of view it would be ideal if, as well as setting the username >and password through setopt, I could also set other authentication parameters, >and then libcurl would use them as if they had been parsed out of the >WWW-Authenticate header. In fact, it would be best to just reuse CURL's >parser: curl_easy_setopt(handle, CURLOPT_HTTPAUTH, CURLAUTH_DIGEST) curl_easy_setopt(handle, CURLOPT_USERNAME, username) curl_easy_setopt(handle, CURLOPT_PASSWORD, password) curl_easy_setopt(handle, CURLOPT_WWW_AUTHENTICATE, "Digest realm=\"Restricted area\",qop=\"auth\",nonce=\"4f8834a7d6315\",opaque=\"cdce8a5c95a1427d74df7acbf41c9ce0\"") curl_easy_perform(handle) If CURLOPT_WWW_AUTHENTICATE is set, curl would parse the string as if it had just been received with a 401 result and use the result to create an Authorization header. (And if the string is malformed, or contains an auth type not included in CURLOPT_HTTPAUTH, then curl_easy_perform would return an error - looks like CURLE_LOGIN_DENIED or CURLE_REMOTE_ACCESS_DENIED would be most appropriate? Or do we need a new error code?) In my case, I would send a request, and when it returned a 401 with a WWW-Authenticate header, I'd save that header, prompt the user for username/password, and then resend the request with the above 4 options set, including copying the value of the WWW-Authenticate header to CURLOPT_WWW_AUTHENTICATE, so that curl could send just one request instead of two. What do you think of this interface? Would you accept a patch to do this? ________________________________________ From: [email protected] [[email protected]] on behalf of Marc Hoersken [[email protected]] Sent: Saturday, April 14, 2012 4:10 AM To: libcurl development Subject: Re: extra requests sent when using HTTPAUTH_DIGEST 2012/4/13 Joe Mason <[email protected]>: > As I understand HTTPAUTH, if I get a URL and the server returns a 401 > response with a "WWW-Authenticate" header, I should resend the request with > an Authorization header. And if I understand curl, it's supposed to be able > to construct the Authorization header behind the scenes. No and yes. You should not resend the same request, because curl actually does it for you if you supply the credentials. > > I've found that whenever I do this, when I call perform on the second > request, curl actually sends 2 requests - one with Authorization and one > without. > > [...] > > So clearly what's happening here is that when I call perform the second time, > curl sends a second request without the Authorized header (to which my server > sends another 401) followed by the request with Authorization (to which my > server sends 200). > > Am I doing something wrong? It depends. If you really need to analyze the headers returned by the first request and then decide to send authenfication inside your own code, you are probably ok. But generally speaking curl also handles the is-auth-required-check for you. This is why an additional request is made and you do not need to perform the very first request yourself. Just tell curl the username and password from the first request on and it will handle everything for you. I don't know any option to disable this behavior, because I think it is part of the HTTP spec. Best regards, Marc ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html --------------------------------------------------------------------- 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
