- From: Mark Nottingham <mnot@mnot.net>
- Date: Mon, 29 Oct 2012 11:57:12 +1100
- To: "Fall, Kevin" <kfall@qti.qualcomm.com>
- Cc: "Adrien W. de Croy" <adrien@qbik.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
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 UTC