Re: HTTP authentication negotiation
Date: Thu, 5 Jun 2008 18:24:17 +0200 (CEST)
On Thu, 5 Jun 2008, Raf Nulens wrote:
>> CURLOPT_SOCKOPTFUNCTION is the option you're looking for. You need to
>> provide the seek/rewind function to allow libcurl to seek back to the
Waaah, I mean to write CURLOPT_SEEKFUNCTION!
> We have been tweaking a bit in libcurl to see if the http authentication
> negotiation can be used when both CURLAUTH_BASIC and CURLAUTH_DIGEST are set.
What do you mean? What would that add that isn't already is working?
> We set conn->bits.authneg = TRUE; in CURLcode Curl_http(struct connectdata
> *conn, bool *done) when we've set a user/pass and CURLAUTH_BASIC |
> In that case Content-length: 0 is sent (without an expect header), and the
> correct expected authentication type is returned by the server in the 401
Ah right, if you by that will insist that there will be authentcation required
and you don't want to allow for a case where it doesn't require auth, then I
can see how that can be a good idea. Still, it should be perfectly clear that
if you then _enable_ two auth options like that you also _disable_ plain no
authentication. The current libcurl code doesn't do that. I would like the
disable bit to be somehow explicitly noticable if we would add something like
this to libcurl.
> Related question: in the release notes for libcurl 7.18.2 we see "libcurl
> sometimes sent body twice when using CURLAUTH_ANY". Is that fix related to
> this 100-continue header issue?
No I don't think so. What you noticed isn't a bug in libcurl. It's a
side-effect caused by a stupid HTTP server (although that 100-continue
behavior is very common) and a limitation in the HTTP protocol.
-- / daniel.haxx.seReceived on 2008-06-05