W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2010

Re: clarity needed for browser behaviors when receiving 206 status codes

From: Marques Johansson <marques@displague.com>
Date: Fri, 25 Jun 2010 20:25:40 -0400
Message-ID: <AANLkTinPuaQoqhSkjJel812HPflKVTCg36YMRGUQc8Ia@mail.gmail.com>
To: "Roy T. Fielding" <fielding@gbiv.com>
Cc: Julian Reschke <julian.reschke@gmx.de>, ietf-http-wg@w3.org, Bjoern Hoehrmann <derhoermi@gmx.net>
On Fri, Jun 25, 2010 at 4:21 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
> This kind of application is not in the HTTP spec because it is a
> poor design -- it sacrifices almost all caching and resource
> identification benefits for the sake of server convenience.
> If the server doesn't want to deliver huge representations
> then it should be delivering a content menu containing links to
> multiple subresources (e.g., Apple's use of a playlist format).

In this case I am dealing with content that would insist upon not
being cached by proxies or UAs.

In the case of cacheable content, the spec already outlines how caches
can reassemble 206 responses to offer larger ranges so long as each
partial responses other headers (cache/expires) matched.

The playlist format introduces a good deal of extra work on the server
because native video files (which are to be supported by html5
browsers) will have to be disassembled into smaller files -
introducing artificial limits on the minimum amount of content a UA
can request and sacrificing cache because each piece of the file has a
unique URL.  To date, this playlist format is supported on Ipads and
Safari.

As for poor design - setting a requirement that a client specify a
range and deal with smaller available data than requested has been a
fixture in computing (filesystem and network sockets).

>> - browsers seem to be ok with a 206 response when no Range was sent -
>> but this should be defined somewhere (changing 'The request MUST have
>> included a Range header field') or by defining a 307+Accept-Ranges
>> behavior or by defining a new '4xx Range Required' status code.
>
> "browsers" is not defined by one implementation.  If such a thing had
> been tried in 1998, it would not have worked on any browsers.  In order
> for us to standardize it now, it would have to be working on all browsers.
> I think we would need to use specific user-agent matching to make it
> work, which would also limit caching.

Accepting a 206 to an unranged request is not something I found in
Chrome alone. Chrome, Firefox, Opera, Links, wget, etc. all accept a
206 status even though they didn't send a Range in their request-
despite the spec suggesting that they should behave otherwise.  If a
server responds with a 206 and the whole content is sent todays
browsers would happily render it.  The point at which browsers deviate
is in how they react to less data being sent than what was requested.
Had these browsers sent a "Range:" in their initial request, only the
WebKit based browsers (arguably the most popular engine in modern
browsers - especially when you include mobile devices) would move to
the next block of ranged content.  (I'm not including IE when I say
"browsers" because I haven't had a chance to test it).

If a 1998 browser attempted to fetch this controlled-range content the
server would give them a '4xx Range Too Large' and that would be the
end of the matter.
Received on Saturday, 26 June 2010 00:26:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:20 GMT