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