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

Thanks.  Reponses inline.

On 9/14/12 5:07 PM PDT, "Mark Nottingham" <mnot@mnot.net> wrote:

>Comments below.
>
>On 14/09/2012, at 1:48 AM, "Fall, Kevin" <kfall@qualcomm.com> 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 <kfall@qualcomm.com>
>> Date: Wednesday, September 12, 2012 3:51 AM PDT
>> To: "fielding@gbiv.com" <fielding@gbiv.com>, "ylafon@w3.org"
>><ylafon@w3.org>, "julian.reschke@greenbytes.de"
>><julian.reschke@greenbytes.de>
>> 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 
><https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p5-ra
>nge.html#rfc.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."""

Yes, but this isn't quite sufficient for what I am asking.
If I ask for the range (0-99) and the server wishes to return to me the
ranges (0-50) and (51-99) separately, this isn't a request for multiple
ranges in one request but does represent multiple range responses.  If
this situation isn't allowed at all (which may be the case given my
reading of the language in 4.1), then I'd like to understand if it could
be.
Why would it be ok to coalesce multiple range requests into a single range
response, but not vice versa?
If the answer is 'because some implementations can't decode
multipart/byteranges but can do single range requests', then see below...

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

I understand that partial content is intended to be OPTIONAL, so let me
ask if this works instead:

Client requests range (0-) [or maybe (0-, 0-) to induce multipart
behavior] with Range header.
Server responds with some byte range(s), hopefully in order but not
necessarily so, and uses Status code 206 to indicate not everything is
necessarily there.

Is this use case to be prohibited?

Thx
- K


>
>Regards,
>
>
>--
>Mark Nottingham   http://www.mnot.net/
>
>
>

Received on Saturday, 15 September 2012 00:53:40 UTC