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

Comments inline.

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

>
>On 15/09/2012, at 10:53 AM, "Fall, Kevin" <kfall@qualcomm.com> wrote:
>
>> 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.
>
>Ah, I see.
>
>> Why would it be ok to coalesce multiple range requests into a single
>>range
>> response, but not vice versa?
>
>Coalescing is primarily to avoid overhead (possibly from a DoS).

I guess that's ok, although if you were really out be annoying it seems
like you could construct requests with many tiny ranges.

>
>> If the answer is 'because some implementations can't decode
>> multipart/byteranges but can do single range requests', then see
>>below...
>
>Yes, that too...
>
>
>>> 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?
>
>
>Imagine that you have two clients, and one of them makes that request a
>minute before the other does.
>
>The first client will see the stream from the beginning.
>
>If the second client goes through the same cache that the first one does,
>it will also see the stream from the beginning (because, from the cache's
>standpoint it's requesting the first *byte* that's been seen).
>
>Is that your intent? Or do you want the second client to see the stream
>"live"? I suspect it's the latter...

Yeah, its the latter case where the issue at hand comes up most in focus.

>
>Range really a mechanism to allow the *client* to request partial
>content; you're wanting to have partial content semantics driven by the
>server. As such, I don't think Range is what you're looking for (unless I
>misunderstand your use case).

I think you do understand the use case.  However, while I believe I
understand the original intent of Range, it seems to me it is a reasonable
if not elegant way to do "server driven" partial content.  Indeed, would
you agree that the method I suggested above (client suggests multiple
ranges including (0-), (0-) would be "legal" to indicate to the server
that it is permitted to repond with multiple ranges of sizes chosen by the
server?

Another angle on the issue:  if Range winds up not being accepted as the
basis for the mechanism of "server driven" partial content, then
undoubtedly somebody is going to suggest some other orthogonal thing for
it (as I think there do exist legitimate use cases for live-style HTTP
streaming).  Personally I'd rather see whatever mechanism it is to be
harmonious with client-side partial content.  (my $0.02).

{FWIW, I'm willing to take a stab at a couple of paragraphs to describe
this 'server driven' case, if the authors of httpbis-p5-range are
amenable.}

Regards,
- Kevin

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

Received on Tuesday, 18 September 2012 17:06:21 UTC