Re: Multiple Range headers in an HTTP request

On Thu, 10 Sep 2009, Raphaël Troncy wrote:

>>> Apache 2.2:
>>> A: Content-Range: bytes 0-99
>>> B: Content-Range: bytes 0-99 (multipart)
>
> So, B should be something like:
>
> HTTP/1.1 206 Partial Content
> Content-type: multipart/byteranges; boundary=A_SEPARATOR
> --A_SEPARATOR
> Content-type: video/mp4
> Content-range: bytes 0-99/50000
> --A_SEPARATOR
> Content-type: video/mp4
> Content-range: bytes 100-199/50000
> --A_SEPARATOR--
>
>>> C: Content-Range: bytes 0-99 (multipart)
>>> D: 200 OK (full resource)
>> 
>> C and D should have been either full resource or the single byte fragment, 
>> but not multipart.
>
> Ah! Why? Because various units are mixed?

Because one unit is not recognized, so either you just ignore it and 
server the single byte fragment, or you stay on the safest side and you 
send back the full resource. Sending a multipart with one part is largely 
sub-optimal.

>>> IIS 5.0:
>>> A: Content-Range: bytes 0-99
>>> B: 200 OK (full resource)
>>> C: 200 OK (full resource)
>>> D: 200 OK (full resource)
>>> 
>>> Conclusion: completely broken with multiple Range headers.
>> Well, no that's perfectly valid to answer with the full resource when 
>> mutiple ranges are requested.
>
> From the latest HTTPBis draft you have sent, it is written:
>
> "A response to a request for multiple ranges, whose result is a single range, 
> MAY be sent as a multipart/byteranges media type with one part.".
>
> So is it expected that the server does some clever processing of the various 
> bytes range requested and actually determine whether they cover or not the 
> same portion?
> You might answer that the server "MAY" do this clever processing :-)

MAY is not a MUST or a SHOULD, it's a MAY ;)
In case of overlapping ranges, of course the server may decide that it's 
an error and send the whole resource. There is an issue about doing DOS 
based on overlapping small ranges.

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Thursday, 10 September 2009 12:27:34 UTC