Re: question/comment on draft-ietf-httpbis-p5-range-20.txt

Comments below.

On 14/09/2012, at 1:48 AM, "Fall, Kevin" <> wrote:

> Hi all.
> I originally posted the question below to the authors of the range-related ID, but they suggested I post to the entire list.  I just joined and am now doing so.  Please see the questions below.
> To provide a bit more background, these questions are coming up in the context of MPEG-DASH, where (potentially real-time generated) media segments are being fetched by a client via HTTP, possibly with Range requests.  As a possible alternative to what I mentioned below in the second half, would it be possible to clarify the use of "Range: 0-" as a request for 'whatever you have available for me right now'.
> Thanks,
> - Kevin
> From: <Fall>, Kevin Fall <>
> Date: Wednesday, September 12, 2012 3:51 AM PDT
> To: "" <>, "" <>, "" <>
> Subject: question/comment on draft-ietf-httpbis-p5-range-20.txt
> Hi folks-
> I was just reading over draft-ietf-httpbis-p5-range-20 and have two small comments/questions.
> First, I see there are no examples where the multipart/byteranges response contains multiple ranges that are out of order.
> As far as I can tell this is ok, but not explicitly mentioned or provided in an example.  If, indeed, this is ok, I believe it would be helpful to mention or illustrate.

Section 4.1 <> says:

"""When a client asks for multiple ranges in one request, the server should return them in the order that they appeared in the request.""" 

> Perhaps more controversial, Section 3.1 requires a Partial Content request to only be permitted if the corresponding request had a Range header field.
> We at least have one case where it would be rather useful to allow a Partial Content / Content-Range response even if the request didn't include the Range header.
> Would it be possible to consider replacing MUST with SHOULD in line #2 of Section 3.1? (along with maybe replacing 'partial GET' with simply 'GET' in line #1)?
> [or similar wording such as Content-Range responses SHOULD only be present in responses if partial GETs were the request types].  I can explain the use case
> in more detail if interested.

This can't be changed; it would change the semantics of a 200 response for clients that don't understand partial content, which is OPTIONAL.


Mark Nottingham

Received on Saturday, 15 September 2012 00:08:16 UTC