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

On 25.06.2010 04:20, Marques Johansson wrote:
> 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?

I don't think they can.

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

A 4xx status, such as 403 Forbidden, comes to mind. However, I wouldn't 
count on any generic client coming to the conclusion that other ranges 
may work on the same resource.

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

Yes.

> ...  There should be a response status the server can use
> in cases where no range was specified but a range is required.

A response code could be defined. Write a spec :-)

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

Me confused.

Could you show an example? If a GET on URI1 returns a 307 with 
Accept-Ranges, and a Location of URI2, why would a client assume that 
URI2 accepts range requests?

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

Well, this is something HTTP range requests obviously haven't been 
designed for. I'm not convinced that they should be used for this, nor 
that making these minor changes would be sufficient to deal with your 
use case.

> ...

Best regards, Julian

Received on Friday, 25 June 2010 13:00:44 UTC