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

RE: Bad browser behaviour?

From: Eric Lawrence <ericlaw@exchange.microsoft.com>
Date: Tue, 20 Mar 2012 17:22:15 +0000
To: Robert Brewer <fumanchu@aminus.org>, Adrien de Croy <adrien@qbik.com>, Adam Barth <w3c@adambarth.com>
CC: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <479CAD406474484E8FA0E39E694732C030BC02D4@DF-M14-02.exchange.corp.microsoft.com>
Most browsers don't warn on Content-Length underruns, and Chunked Encoding typically has the same behavior.

We have seen some real-world scenarios where a server using Chunked never sends the trailing 0CRLFCRLF and simply closes the connection. There are two scenarios of interest when considering the premature closure-- 1> where the last block was of the promised size (e.g. server promised n bytes and sent n) and 2> where the last block was shorter than the promised size when the connection was closed. The latter is obviously somewhat more "suspicious" than the former.

-----Original Message-----
From: Robert Brewer [mailto:fumanchu@aminus.org] 
Sent: Tuesday, March 20, 2012 8:35 AM
To: Adrien de Croy; Adam Barth
Cc: HTTP Working Group
Subject: RE: Bad browser behaviour?

Adrien de Croy wrote:
> On 20/03/2012 6:53 p.m., Adam Barth wrote:
> > On Mon, Mar 19, 2012 at 10:37 PM, Adrien W. de Croy<adrien@qbik.com>
> wrote:
> > > OK, so what we're saying is that the 0 chunk is basically 
> > > redundant.
> > 
> > What if you want to send another response?  Don't you need to 
> > terminate the first response somehow?
> ok, I'll re-phrase.  The 0 chunk becomes expendable if the server 
> closes.
> this isn't much different to the case where there's no content length 
> and the server closes without chunking.
> IMO we should use the information we get though.

This is a serious problem at my current company, where we regularly stream large CSV output of survey results to clients. If something goes wrong on the server after the response headers have been written but before the complete dataset has been written out, then it has been considered proper to simply end the connection on the server side (what else could it do? too late to change the response status).
Unfortunately, most browsers don't warn the user that they have received a partial dataset, and it's only perhaps days later that someone notices their analyses are way off the expected results. Sometimes they don't notice at all, which can become a serious issue (think: clinical studies informing public policy; won't somebody please think of the children?).
IMO therefore, all clients should be encouraged to fail loudly if the connection is closed by the server before a 0 chunk is reached, since there is no other mechanism for a server to communicate that there has been an error (at least not a generic one; in our case of a CSV file, and assuming the error occurs in the server's application layer and can be trapped, we could try to emit a plain text warning or garbage bytes; however, this is not a good strategy for all media types, nor does it address errors in lower-level code).

Robert Brewer
Received on Tuesday, 20 March 2012 17:22:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:01 UTC