cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: Problem using negotiated NTLM authentication with IIS 6 & post-data

From: Jamie Lokier <jamie_at_shareable.org>
Date: Tue, 15 Feb 2005 13:23:15 +0000

Christopher R. Palmer wrote:
> >What curl version is this? I trust you at least tried this with the
> >latest version to make sure we haven't fixed it since? The 'anyauth'
> >magic has been written, rewritten and yet again rewritten (yes a third
> >time). I believe the last version is the correct version as this was
> >debated, discussed and tested a lot.
>
> Sorry, yes, I guess I forgot to mention that I tested this using the
> lastest CVS snapshot (which was 20050211 as of last night).
...
> == Info: About to connect() to 192.168.0.135 port 80
> == Info: Trying 192.168.0.135... == Info: connected
> == Info: Connected to 192.168.0.135 (192.168.0.135) port 80
> => Send header, 303 bytes (0x12f)
> 0000: POST /_vti_bin/search.asmx HTTP/1.1
... headers ...
> 0101: Content-Length: 2407
> 0117: Expect: 100-continue
> 012d:
> <= Recv header, 27 bytes (0x1b)
> 0000: HTTP/1.1 401 Unauthorized
> <= Recv header, 22 bytes (0x16)
> 0000: WWW-Authenticate: NTLM
> <= Recv header, 23 bytes (0x17)
> 0000: Date: Tue, 15 Feb 2005 11:31:41 GMT
> == Info: Ignoring the response-body
> <= Recv data, 1216 bytes (0x4c0)
... response body ...
> == Info: Connection #0 to host 192.168.0.135 left intact
> == Info: Issue another request to this URL: 'http://192.168.0.135/_vti_bin/search.asmx'
> == Info: Re-using existing connection! (#0) with host 192.168.0.135
> == Info: Connected to 192.168.0.135 (192.168.0.135) port 80
> == Info: Server auth using NTLM with user 'vivisimo/crpalmer'
> => Send header, 344 bytes (0x158)
> 0000: POST /_vti_bin/search.asmx HTTP/1.1

... voila! A bug in curl! ...

It's sending POST with non-zero Content-Length but no request body.
Then it's sending POST again on the same connection: that's always an
error -- even with IIS :)

Daniel, at the last anyauth rewrite, this was what you wrote to the list:

>> 1. PUT/POST without a known auth to use (possibly no auth required):
>>
>> (When explicitly set to use a multi-pass auth when doing a
>> POST/PUT, libcurl should immediately go the Content-Length: 0
>> bytes route to avoid the first send all data phase, step 2. If
>> told to use a single-pass auth, goto step 3.)
>>
>> Issue the proper PUT/POST request immediately, with the correct
>> Content-Length and Expect: headers.
>>
>> If a 100 response is received or the wait for one times out,
>> start sending the request-body.
>>
>> If a 401 (or 407 when talking through a proxy) is received, then:
>>
>> If we have "more than just a little" data left to send, close
>> the connection. Exactly what "more than just a little" means
>> will have to be determined. Possibly the current transfer speed
>> should be taken into account as well.

However, from Christopher's trace, when we have "more than just a
little" to send, it's not closing the connection - it's just not
sending the request body.

>From anything thing he said, when we have only a little to send, then
it's fine - it does send the request body.

That's the bug. Solution is to close the connection when deciding to
not send the request body, just as you intended :)

-- Jamie
Received on 2005-02-15