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
fumanchu@aminus.org

Received on Tuesday, 20 March 2012 15:36:33 UTC