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

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

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

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

Cheers,

--
Mark Nottingham   http://www.mnot.net/

Received on Saturday, 15 September 2012 01:04:45 UTC