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

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

From: Dale Anderson <dra@redevised.net>
Date: Fri, 26 Aug 2011 13:35:13 -0700
Message-ID: <CANNRn6LO6qg3r63y4sAHN3NUX0KPH9hi9jdVLtVGP3eZWFP-dg@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
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

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


Dale Anderson
Received on Friday, 26 August 2011 20:35:50 UTC

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