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: Mark Nottingham <mnot@mnot.net>
Date: Sat, 27 Aug 2011 19:41:00 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Yves Lafon <ylafon@w3.org>
Message-Id: <1EAA8D29-9ECA-46BA-B804-053BE4EC8509@mnot.net>
To: Dale Anderson <dra@redevised.net>
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,


On 27/08/2011, at 6:35 AM, 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.
> 
> 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
> 

--
Mark Nottingham   http://www.mnot.net/
Received on Saturday, 27 August 2011 09:41:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:47 GMT