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

On Thu, Jun 24, 2010 at 11:47 PM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
>>How can servers inform clients that all requests must be made with
>>ranges specified?
>
> As far as byte ranges are concerned, if the server is willing to accept
> a range request for the "whole" resource, then the server should not in-
> sist on the client making a range request. If it is not then the server
> would need to tell the client what ranges are available, but that seems
> to be more a 300 Multiple Choices kind of situation.

The server may be willing to accept a range for the "whole" resource
if the user purchased access to the whole video rather than paying by
the byte/second/minute.  That is really a different matter and one
that would not create any problems.

In this case, the server is not willing to accept an un-ranged request
or range request for the "whole" resource. The server wants to give
the user no more content then the user and host service have
authorized.

Example: The user purchases 10 minutes of time from a video on demand
service.  The server based on some agreement will give the browser no
more than 5 seconds of video at a time in the form of a partial
result.  This sets a streaming heartbeat that prevents the browser
from fetching the entire file and thus deducting the user for content
they did not want.  The server can also throttle the client if it
detects that the user agent is attempting to sequentially request data
faster than real-time (in terms of the video's play position).  In the
case of Chrome and the Ogg handler in Opera, the ranged requests come
from the user-agent as the content is needed - they do not attempt to
prefetch the data (the HTML video element provides attributes for
this).

There are three problems with a 300 in this case.
- there is no spec defined follow up behavior - a 307 on the other
hand informs the UA to try again
- all multiple choices have the same URL: file.mp4 (only Accept-Ranges
would differ)
- there are millions of choices available: Range:
(x1=0...size-1)-(x2=x1+1...size).

>>How should a client or server respond when the server is not willing
>>to fulfill the entire range requested by the client?
>
> That depends on why it is not willing and possibly what could sway the
> server to satisfy the request. Payment Required, Service Unavailable,
> Unauthorized, and so on. In doubt 403 Forbidden with an Accept-Ranges
> header in the response and a suitable entity body would seem sensible;
> that also goes for your first question.

The problem with a 403 is that it creates an impasse.  There is no
spec defined behavior for a browser to receive a 403 with
Accept-Ranges headers and then re-request the content with Ranges.
The 307 response gets the ball rolling which is why I suggested that
this behavior be formalized (since some of the major UAs already
support this).

This is why I suggested a new 4xx to indicate that ranges are
required.  Any other range related problems can be handled with a 416.
 If a UA doesn't understand this new error code (or how to use ranges)
then they will naturally stop processing at this point, which is the
intention of the server.

>> The spec should permit and document a method for handling 206
>> responses in this continues way
...
>> 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.

If there was a "Accept-Range-Max-Length" header then the large number
of multiple choices problem would be solved without resorting to a 416
on each request that lacked an upper bound.  Or the spec could tell
UAs to follow WebKit's lead and simply expect that the server may
return less data than requested by the Range and this should prompt
the UA to follow-up with additional range requests as needed.

Received on Friday, 25 June 2010 11:48:25 UTC