W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2012

Re: draft-kfall-httpbis-server-ranges [was: Preliminary agenda for Atlanta]

From: Fall, Kevin <kfall@qti.qualcomm.com>
Date: Fri, 26 Oct 2012 03:06:16 +0000
To: "Adrien W. de Croy" <adrien@qbik.com>, Mark Nottingham <mnot@mnot.net>
CC: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Message-ID: <BB72E60F7A18154A9B1352D1DF6FEE571E2692A3@NASANEXD01E.na.qualcomm.com>
The real world reason this comes up is described in the draft. [basically,
portions of multimedia segments]
The issue is when the server has some portion of an entity that may be out
of sequence from the start.
(that is, the server may have 200-300 but not 100-200.  The client may ask
later for 100-200 or decide to move on without those parts).

I was hoping to have a few mins at the ATL meeting to describe how/why
this issue comes up.

thx
- K

On 10/25/12 3:55 PM PDT, "Adrien W. de Croy" <adrien@qbik.com> wrote:

>
>Hi
>
>------ Original Message ------
>From: "Fall, Kevin" <kfall@qti.qualcomm.com>
>To: "Mark Nottingham" <mnot@mnot.net>
>Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
>Sent: 26/10/2012 2:32:44 a.m.
>Subject: Re: draft-kfall-httpbis-server-ranges [was: Preliminary agenda
>for Atlanta]
>>That is one case, but perhaps more interesting/controversial is this one:
>>
>> Range: bytes=100-
>>
>> Content-Range: bytes 200-300/1000.
>>
>
>I'm struggling to see the point of this.
>
>What real world case would something like this solve?  Presumably the
>client would need to request 100-200 again?  If not, then why even deal
>in bytes and part ranges like this at all?
>
>Regards
>
>Adrien
>
>
>>
>>
>>A subsequent request might likely then be:
>>
>> Range: 100-200, 300-1000
>>
>>for which the responses might be
>>
>> Content-Range: 100-200, 300-1000
>>
>>or even something like
>>
>> Range: 100-1000
>>
>>(although this later case isn't as desirable due the redundancy).
>>
>>It would still be straightforward to implement the current rule of not
>>returning multiple ranges unless multiple ranges were given in the
>>request.
>>Although I don't know if the intent is to continue with this guidance
>>given a new HTTP version. [?]
>>
>>A related issue is which response code to use for such responses.
>>Although 206 seems most logical given the current set of defined codes
>>(it
>>is, after all, 'Partial Content'), perhaps it might be more clear if a
>>different code were used.  I'm neutral on that issue for the moment; the
>>draft suggests 206.
>>
>>thx
>>- K
>>
>>On 10/24/12 8:32 PM PDT, "Mark Nottingham" <mnot@mnot.net> wrote:
>>
>>
>>>
>>>Kevin,
>>>
>>>On 23/10/2012, at 3:11 PM, "Fall, Kevin" <kfall@qti.qualcomm.com> wrote:
>>>
>>>
>>>>
>>>>Would like a chance to briefly bring up the range / partial delivery
>>>>issue
>>>>I mentioned on the list.
>>>>[and what's behind
>>>>http://tools.ietf.org/id/draft-kfall-httpbis-server-ranges-00.txt]
>>>>
>>>
>>>
>>>
>>>We can spend a bit of time on it in the "related work" item of the
>>>session on Monday, yes.
>>>
>>>To make the use case a bit more concrete, and make sure I understand it,
>>>one example AIUI would be a request for
>>>
>>> Range: bytes=100-
>>>
>>>to which you return, say:
>>>
>>> Content-Range: bytes 100-200/1000
>>> ETag: "1234"
>>>
>>>and then to a subseqent, identical request
>>>
>>> Content-Range: bytes 100-400/1000
>>> ETag: "1234"
>>>
>>>Correct?
>>>
>>>Cheers,
>>>
>>>
>>>--
>>>Mark Nottingham   http://www.mnot.net/
>>>
>>>
>>>
>>>
>>
>
Received on Friday, 26 October 2012 03:06:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 26 October 2012 03:06:57 GMT