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: Zhong Yu <zhong.j.yu@gmail.com>
Date: Thu, 25 Oct 2012 10:48:05 -0500
Message-ID: <CACuKZqHBgwbnL5O4dgJe82-hDcZDbpiG3yStX18TKrTmg71z4w@mail.gmail.com>
To: "Fall, Kevin" <kfall@qti.qualcomm.com>
Cc: Mark Nottingham <mnot@mnot.net>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Could your use cases be solved by a new transfer coding?

For example, a "shattered" coding, where entity body is transmitted in
pieces, and the pieces are in undetermined order:

  GET /data HTTP/1.1
  TE: shattered

  HTTP/1.1 200 OK
  Transfer-Encoding: shattered, chunked

  message_body=chunked(
    "500-600:" data[500-600]
    "150-300:" data[150-300]
    ....
    )

Client can specify range filters

  GET /data HTTP/1.1
  Range: bytes=1000-
  TE: shattered

  HTTP/1.1 206 Partial Content
  Content-Range : 1000-N/N
  Transfer-Encoding: shattered, chunked

  message_body=chunked(
    "700-800:" data[1700-1800]
    "200-300:" data[1200-1300]
    ....
    )

Zhong Yu

On Thu, Oct 25, 2012 at 8:32 AM, Fall, Kevin <kfall@qti.qualcomm.com> wrote:
> 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 15:48:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 25 October 2012 15:48:39 GMT