W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2011

Re: idea for a helpful short discussion to add into section 5 (ranges)

From: Yves Lafon <ylafon@w3.org>
Date: Tue, 30 Aug 2011 08:35:27 -0400 (EDT)
To: Dale Anderson <dra@redevised.net>
cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <alpine.DEB.1.10.1108300822120.21549@wnl.j3.bet>
On Fri, 26 Aug 2011, Dale Anderson wrote:

> Hi, just for context first - I have/had to write some tests for range
> requests for a cache product with respect to our handling for cached
> vs. uncached, valid vs. invalid, single vs. range requests, that type
> of thing.
> I and my comrades remained confused for a week or so until I really
> dug through section 5 and came to this understanding on the following
> understanding. First, as a straw-man argument let me set up our
> initial opinion.
> (straw-man argument): "A client who is asking for ranges in any way
> exceeding the bounds of a static resource is clearly not knowing what
> it is asking for ranges of and should get 416 or similar client
> error."
> After more careful review of part 5 I came to the understanding that a
> client might initiate a download and begin a large file transfer occur
> in the chunked encoding, so client has no knowledge of content length.
> The transmission is terminated by the client or on accident. To
> resume, the client might request from the lost point up to some buffer
> amount more, like a megabyte, and the server then would sensible
> provide the satisfiable portions of the range.

Another use case is a memory-constrained client that request up to the 
amount of buffer it has until it reaches the end of the file.

GET /foo HTTP/1.1
Host: www.example.com
Range: bytes=0-1024

If http://www.example.com/foo is smaller than 1024 bytes, then yes the 
requested range was bigger than the size of the resource representation, 
but the size is not known in advance.

> OK. My suggestion the first is that some language be consolidated not
> too far from the beginning of part 5, to explain that conclusion very
> succinctly, including reference to the chunked format for the reader
> to gain this understanding properly.
> Key existing relevant parts from the r16 draft part 5 that led me to
> this understanding:
>  - second paragraph in section 4 "Combining Ranges"
The unfinished shunked encoding use case is covered by "an incomplete 200 
Would adding a reference to part 1, section 3.3 on the definition of the 
Message Body ?

>  - fourth paragraph in section 4 "Combining Ranges"
>  - third paragraph in section 5.1 "Accept-Ranges" (starts w/ The
> header field SHOULD....)
> Of course, feel free to clarify my understanding if my conclusion was
> flawed, but that's my take-away and my approach to my tests' expected
> results.
> Respectfully,
> Dale Anderson

Baroula que barouleras, au tiéu toujou t'entourneras.

Received on Tuesday, 30 August 2011 12:35:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:58 UTC