On Fri, May 6, 2005, man_at_tfhs.net said:

> On Thu, May 5, 2005, Daniel Stenberg <daniel-curl_at_haxx.se> said:
>
>> On Thu, 5 May 2005 man_at_tfhs.net wrote:
>>
>>> i am getting a tcp dump now, i will send it to you directly rather than to
>>> the list. basically, 14 packets come in, then no more, and after the
>>> timeout, libcurl returns. it likely could have returned sooner on seeing the
>>> FIN's from the squid box
>>
>> Here's what I believe happens (based on data Allan provided me, my output here
>> is a cut n' pasted edited version of his logs - not an exact copy):
>>
>> libcurl first sends:
>>
>> POST [URL] HTTP/1.1
>> User-Agent: blabla
>> Host: blabla
>> Pragma: no-cache
>> Accept: */*
>> Content-Length: 9809
>> Content-Type: multipart/form-data; boundary=-----yadayada
>>
>> The proxy then responds with:
>>
>> HTTP/1.0 407 Proxy Authentication Required
>> Server: squid/2.5.STABLE1
>> Content-Length: 1340
>> X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0
>> Proxy-Authenticate: Basic realm="Squid proxy-caching web server"
>> Proxy-Connection: close
>>
>> [1340 bytes of HTML]
>>
>> Server sends TCP FIN.
>>
>> ... since libcurl didn't use an Expect-header, it continues and sends away
>> 9809 bytes of formdata. It actually only manages to send two TCP packages,
>> both with 1448 bytes of HTTP data (in each).
>>
>> The server then sends TCP RST (twice).
>>
>> Then the captured trace ends.
>>
>> I don't see why libcurl doesn't detect this (FIN/RST) and stops the
>> transfer...
>
> i have tried running my app quite a few times, and the number of packets
> that libcurl tries to send into the FIN connect varies, usually 2 or 3,
> but extremely rarely, it actually works. i have not managed to get a
> tcpdump of that yet, but i am still trying. so this is looking more timing
> related?
>

ok, i caught a dump of it actually working. i increased the network load
on the client (by doing a big `find` on an nfs mount), and the 407 is not
received until after the entire body has been sent to the proxy, then the
connect is torn down, libcurl opens it again, and sends with the auth
headers added.

so it seems like libcurl will handle the 407/FIN after the body is sent,
but not before...

daniel, you want a dump of this (much larger)?

allan
Received on 2005-05-06