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

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 
(OK)".
Would adding a reference to part 1, section 3.3 on the definition of the 
Message Body ?
https://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-16#section-3.3

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

         ~~Yves

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