W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: Dealing with bad server chunking

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 15 Mar 2013 11:38:36 +0100
Message-ID: <5142FA2C.1050408@gmx.de>
To: Daniel Stenberg <daniel@haxx.se>
CC: "Adrien W. de Croy" <adrien@qbik.com>, IETF HTTP Working Group <ietf-http-wg@w3.org>
On 2013-03-15 11:13, Daniel Stenberg wrote:
> On Fri, 15 Mar 2013, Adrien W. de Croy wrote:
>
>> we have recently had issues with a site where the server sends chunked
>> responses back but closes the TCP connection prior to sending any 0
>> chunk (in fact we never see a packet with this).
>>
>> WinGate detects this as an abortive close, and if there were any
>> filters processing the stream, they are reset, and the data may not go
>> to the client.
>>
>> However, client browsers typically "forgive" this transgression
>> without any sort of warning.  Should we be making more forceful
>> suggestions about this in the specs?
>
> IMHO, a broken transfer is a broken transfer. How can you know it is
> only a 0 chunk that is missing and not any further chunks?
>
> If browsers don't warn about broken transfers then I think that's their
> choice but it is not saying that it was a fine transfer as far as the
> actual HTTP transfer goes.
> ...

One thing are truncated web pages (might be detectable by the user), one 
thing are truncated downloads (very bad).

That being said, Chrome and Firefox recently have become more picky with 
respect to malformed header fields (such as Content-Length), so if they 
get this wrong now, there's chance it might get fixed.

This obviously needs test cases.

Best regards, Julian
Received on Friday, 15 March 2013 10:39:07 GMT

This archive was generated by hypermail 2.3.1 : Friday, 15 March 2013 10:39:09 GMT