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
>> beginning.

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 |
> CURLAUTH_DIGEST.
>
> 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
> message.

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.se