curl-library
Re: "Received problem 2 in the chunky parser" Error ?
Date: Thu, 6 Apr 2006 13:23:24 +0300
Hi,
Attached is the FireFox dump and the chunks look fine in it.
I successfully tracked the problem to the "Connection:" header. It seems that
if the "Connection: keep-alive" request header is not sent the server will
respond with data which is not chunked . It will still reply with a
"Transfer-Encoding: chunked" response header though.
I don't think this behavior is normal and it is not a cURL problem. I'll
consider the case closed but if somebody wants to make something about it I
can send additional info and test it further.
Best regards
Dobromir Velev
On Thursday 06 April 2006 01:00, Daniel Stenberg wrote:
> On Wed, 5 Apr 2006, Dobromir Velev wrote:
> > I've run into a strange error when trying to open a chunked page on a
> > Rapid Logic server. The page opens fine on other browsers or when curl is
> > forced to use HTTP/1.0.
> >
> > Any ideas?
>
> If you can repeat this on demand, we surely are in a good position to nail
> this. I've seen it reported before, but then people have just been happy
> with the 1.0-workaround and moved on...
>
> > <= Recv data, 314 bytes (0x13a)
>
> Below here is the first chunk of data libcurl reads:
> > 0000: 3c 68 74 6d 6c 3e 0d 0a 3c 68 65 61 64 3e 0d 0a <html>..<head>..
> > 0010: 3c 74 69 74 6c 65 3e 4c 6f 67 20 4f 6e 3c 2f 74 <title>Log On</t
> > 0020: 69 74 6c 65 3e 0d 0a 0d 0a 3c 73 63 72 69 70 74 itle>....<script
>
> Notice how this _does not_ start with a hexadecimal chunk size followed by
> a CRLF. This is truly an illegal chunked transfer. Baaad server.
>
> (And we should probably improve that error message libcurl shows for this
> error condition.)
>
> If you snoop on the traffic when you fetch with Firefox or similar, can you
> see if it gets the same (bad) chunked transfer? If so, can you see if it
> gets _any_ chunks or if it all just get sent completely without chunks?
>
> I'm not sure how to work around this server bug though. Without chunks,
> there's no way we can know when there's no more data to expect from the
> server...
- text/plain attachment: firefox.dump.txt