On Wed, 31 Jan 2007, keiichi molisado wrote:

> I am using libcurl version 7.16.0 under Microsoft Visual C++ to write an
> HTTP client. A problem concerning digest authentication occurs when this
> client performs HTTP PUT to communicate with an HTTP server which does not
> enable digest authentication.

Just a first question already at this point. What's the target server here?
Are you sure it speaks HTTP 1.1 as the RFC explains it?

> If the client enables digest authentication in libcurl, i.e., set
> CURLOPT_HTTPAUTH, the packets captured by Ethereal show that the PUT request
> does not carry a body, which is regarded as an error by the HTTP server.

How do you deem this is an error in libcurl and not in the server?

Why use ethereal at all to trace what libcurl does? I find CURLOPT_VERBOSE and
CURLOPT_DEBUGFUNCTION easier to get protocol info from/with.

Besides, I'm quite sure it _does_ "carry a body" if the server just responds
fine to libcurl.

Are you setting Digest only, or do you allow multiple authentications?

Can you provide source code for a simple app showing this problem?

> On the other hand, if the client disables digest authentication in libcurl,
> the packets show that the PUT request does carry a body and therefore can be
> handled by the HTTP server. However, although there is only one packet
> labeled as HTTP PUT by Ethereal, a preceding packet is labeled as "[TCP
> segment of a resembled PDU]", of which the "TCP segment data" contains an
> HTTP PUT with request line and headers only.

... and that's one reason why the libcurl options will procuce better debug
logs.

> Therefore, it seems that the behavior of HTTP PUT (carry a body or not) is
> affected by the desicoin of enabling digest authentication or not.
> Originally I guess this is a normal behavior of digest authentication
> because libcurl "thinks" there is no need to carry the body in the 1st PUT
> request since a 2nd PUT request will surely be sent to complete the digest
> authenticaiton process. But this does not make sense from the perspective of
> the client since it has no idea in advance about whether the HTTP server
> enables digest authentication or not.

Digest is a challange-response kind of authentication. It means that the first
request needs to get a response back, and then a second request can be done
properly authenticated. Thus, the initial request can never be "let through"
since it isn't authenticated.

What is the server's full response on the first PUT request? And how does the
request headers from libcurl's initual PUT request look like?

> I found a topic about the behavior of "Expect" header handling (please refer
> to the disscussion on "Libcurl request generating HTTP/1.1 411 Length
> Required error" and "bad PUT" during 2003.12 ~ 2004.02). But if this is the
> case, there should be no difference caused by "enabling digest
> authentication or not", since the "Expect" header is included in the PUT
> requests in both cases.

Right, but in the case with no authenticaion I would expect the server to
respond positively at once, while in the authenticated case it would (ideally)
not respond "100 continue" but instead a 401.

See test case 88, which is doing a PUT with Digest auth.

> As a result, I would like to know whether the PUT behavior in libcurl is
> really affected by the desicion of digest authentication,

It MUST be affected by digest so I surely hope it is.

> if this is the case, how can I use libcurl to communicate with HTTP servers
> regardless of their support of digest authentication?

Possibly there is a bug in libcurl, possibly there is a bug in your receiving
server and possibly you're not using libcurl right. I think we need more and
specific details to be able to figure it out.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html