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?

allan
Received on 2005-05-06