clarity needed for browser behaviors when receiving 206 status codes

The HTTP specification for ranges does not deal with a few range
related matters that I encountered while attempting to create a
streaming video script.

How can servers inform clients that all requests must be made with
ranges specified?

How should a client or server respond when the server is not willing
to fulfill the entire range requested by the client?

When a client makes a GET request without sending a Range: header, the
server can still reply with a 206 status, providing an Accept-Ranges
header, and providing some arbitrary segment of data (hopefully
starting at range byte 0).  This seems to catch many of todays
browsers off guard.  They use the data they were given, but they do
not follow up with subsequent Range requests.

According to the spec, the server can only reply with a 416 if a Range
was requested.  There should be a response status the server can use
in cases where no range was specified but a range is required.

A way to prime some web browsers to send Range: requests is to send
the Accept-Ranges: header in a 307 redirect response to the initial
un-ranged request.  The behavior of following this redirect and
sending a partial request is not taken by many text based browsers but
appears to be taken by modern desktop browsers.

Now that the browser is sending a Range with its request, what happens
when the server does not wish to return all of the data requested.
All browsers send something like: "Range: bytes=0-".  When the server
replies with an incomplete result in a 206 response browsers tend to
stop fetching (not always true - Chrome continues to fetch).  It seems
that the specification, by not bringing this point up, would have a
server respond with a 416 specifying a corrected range which the
browser would then request.  This doubles the transaction count which
is especially problematic for scenarios where the server is only
willing to return segments of content with a specific size.

If the server could respond with a "Accept-Range-Max-Length:" then
there would only be need for a single 416 response or this header
could be included with the 307 response.

In the section on content negotiation the spec seems to favor that the
client should do its best to process the response that the server
supplied.  Chrome appears to be doing this in the case of 206
responses to un-ranged requests.

The spec should permit and document a method for handling 206
responses in this continues way or provided a means for the server to
inform the client that ranges must be specified

The spec should also prescribe a behavior for handling incomplete
range results or a method for the server to state their intention to
return constrained length responses.

It should also be considered that a server could forever send a client
the wrong response data, or only tiny responses, and cause a denial of
service on the client - however, this is not too different from any
case where the server would return a simple large response.  The
client always has the option to refuse fetching the range.

See these postings for additional commentary:
 https://bugzilla.mozilla.org/show_bug.cgi?id=570755
 http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026837.html

Received on Friday, 25 June 2010 02:21:00 UTC