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: Mark Nottingham <mnot@mnot.net>
Date: Mon, 29 Oct 2012 11:57:12 +1100
Cc: "Adrien W. de Croy" <adrien@qbik.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Message-Id: <9DD2B4C9-3C33-4DF2-A332-75B0C31AD986@mnot.net>
To: "Fall, Kevin" <kfall@qti.qualcomm.com>

On 26/10/2012, at 2:06 PM, "Fall, Kevin" <kfall@qti.qualcomm.com> wrote:

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

Yes, you're on the agenda. If you have slides, please send them to me beforehand (ideally, in the next few days).

Cheers,


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

--
Mark Nottingham   http://www.mnot.net/
Received on Monday, 29 October 2012 00:57:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 29 October 2012 00:57:36 GMT