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

From: Dale Anderson <[email-masked]>
Date: Fri, 26 Aug 2011 13:35:13 -0700

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.

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

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 27 Aug 2011 19:41:00 +1000

Hi Dale,

Thanks for taking the time to give feedback. Yves (CC:ed) is the editor who usually has the pen for part 5, and I think your suggestions can be taken as editorial input. 

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: Yves Lafon <[email-masked]>
Date: Tue, 30 Aug 2011 08:35:27 -0400 (EDT)

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

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

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

         ~~Yves