Hi,
I applied the patch but it doesn't work in this case. cURL tries to send the
request to the URL in the Location header, but since there is still data to
read from this connection it will read the content from the first request,
and stops before reading the data from the second request. See the attached
trace file for details.

This is definetely a programming bug on the website, and will be fixed,
though it works fine in IE and Firefox. I know you're trying to keep cURL
RFC compilant and there is no need to deal with such buggy implementations.

Thanks for the help

Dobromir Velev

On 12/2/06, Daniel Stenberg <daniel_at_haxx.se> wrote:
>
> On Sat, 2 Dec 2006, Dobromir Velev wrote:
>
> > I also noticed that there is no Conent-length header and it is what is
> > causing the problem. I'm now trying to add a workaround in
> lib/transfer.c to
> > avoid the timeout error for this particular case.
>
> Any ideas on how you'd do that? In HTTP there is basically three ways for
> a
> client to know when the response is done: 1) connection closed 2)
> Content-Length 3) chunked encoding. The response you got had none of these
> so
> a client has no means to know where/when it stops.
>
> Since a response body MUST be preceeded with enough info for a client to
> know
> the end of it, the change below is now in CVS:
>
> http://cool.haxx.se/cvs.cgi/curl/lib/transfer.c.diff?r1=1.319&r2=1.320
>
> ... and using this, libcurl would not read the response you got and it
> wouldn't hang like this. However, I'm not saying it is the perfect
> solution
> for your case since one bad response is usually followed by other protocol
> weirdos.
>
> --
> Commercial curl and libcurl Technical Support: http://haxx.se/curl.html
>

-- 
Dobromir Velev
---------------------------------------------------------------------------
"Never attribute to malice that which can be
adequately explained by stupidity"