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

Re: Bad browser behaviour?

From: Roy T. Fielding <fielding@gbiv.com>
Date: Tue, 20 Mar 2012 13:39:16 -0700
Cc: "Adrien de Croy" <adrien@qbik.com>, "Adam Barth" <w3c@adambarth.com>, "HTTP Working Group" <ietf-http-wg@w3.org>
Message-Id: <5315977F-4E73-44BC-B36E-C6F45DF5DB30@gbiv.com>
To: Robert Brewer <fumanchu@aminus.org>
On Mar 20, 2012, at 8:35 AM, Robert Brewer wrote:

> 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?).

Yes, this is in fact a well-known bug in some browsers.  That is why the
HTTPbis spec has the following REQUIREMENT in p1 sec 3.4:

   A user agent MUST NOT render an incomplete response message body
   as if it were complete (i.e., some indication must be given to the
   user that an error occurred).

We don't require a specific UI, but it should be obvious to developers
why silent truncation of a page can be life-threatening in many contexts
where browser-based applications are in use today.  It is not difficult
to add the equivalent of a broken-image icon (or an off-color line with
a tooltip, or spoken phrase, or a fail whale, or whatever might be an
appropriate error stream for a command-line tool) at the end
of a truncated page or embedded element.


Roy T. Fielding                     <http://roy.gbiv.com/>
Principal Scientist, Adobe Systems  <http://adobe.com/enterprise>
Received on Tuesday, 20 March 2012 20:39:39 UTC

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