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

On Jun 25, 2010, at 8:27 AM, Marques Johansson wrote:

> Yes, I don't think the HTTP range spec was specifically designed for
> this but it nearly fits the application of controlled content
> streaming and doesn't try to block this application.  My response is
> sort of long and includes various ways to address my concerns so I
> added flow interrupting headings (joy).

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

> ==  Sending smaller than requested ranges in a 206 ==
> 
> If the spec spelled out how to handle smaller responses (as WebKit
> handles these) we could circumvent the unnecessary error and
> redirection phase:
> 
> In Webkit it works like this:
>  GET /file.mp4 HTTP/1.1
>  ...
>  HTTP/1.1 206 partial (smaller than requested)
>  Content-Range: bytes 0-99999/300000
>  ...
>  GET /file.mp4 HTTP/1.1
>  Range: bytes=100000-
>  ...
>  HTTP/1.1 206 partial (smaller than requested)
>  Content-Range: bytes 100000-199999/300000
> 
> Despite http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-09#section-3.1
> - 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.

....Roy

Received on Friday, 25 June 2010 20:22:23 UTC