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.

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 Thursday, 25 October 2012 13:33:31 UTC