Re: 14.36

Jeff writes:
> The utility of allowing what the current draft allows is that,
> for example, a client with a restricted memory and/or network
> bandwidth (think: wireless PDA) could do a request such as this:
> 
> 	GET /foo.html HTTP/1.1
> 	Range: 0-10000
> 
> and be assured of not getting more than 10,000 bytes.  This is
> far more efficient than having the client try to abort the
> response because it cannot take any more data.  And I believe
> that the specification is well-defined, in the sense that the
> client can tell from the response headers exactly what it has
> received.

Jeff,
	I don't think it is that simple.  If the client requests the
byte range from 0-10000 to insure it doesn't get more than 10,001
bytes of data at a time, it succeeds under both our proposals.  Under
yours, the client gets from 0 to the end of the resource; under mine,
the client gets "the whole entity".  Under either system this is under
the 10,001 bytes the client will accept.
	Note, howver, that this will not be the case if the first
byte requested is not byte 0.  Under your proposal, if the requested
byte range is 10,000-20,000 and the resource ends at 14,678, the
client gets 10,000-14,678.  Under my proposal, the client gets the
whole 0-14,678.  
	Thinking about this, I see that there is an assumption in my
model that we do not seem to share; I believe that clients should
retain information about the content length when they have partial
content that they are building up in ranges.  So, under my
assumptions, the PDA client would request byte range 0-10000, get the
first 10,001 bytes of a resource larger than 10,001 bytes *and the
content length of the resource*.  It should then use that contact
length in collecting any later ranges from that resource.  If the
client works according to my assumptions, the usefulness of allowing a
byte range which extends beyond the last-byte-pos is very limited
indeed.  Since we have not specified them, my assumptions may well, of
course, not be those used by a client designer working on this
problem.
	Beyond that set of design assumptions, I also believe that
there is a downside to allowing the byte range to extend beyond the
last-byte-pos; it can force an extra round trip for clients which are
building up a resource from ranges and are not using conditional GETs.
I agree that the use of conditional requests can help maintain
semantic transparency for range requests, but the text of 14.36.2
makes it quite clear that a client may request a range without using
such conditions.  
	I worry that a client implemented to use a global setting for
resource freshness (like check once per session/check every time/check
never) will apply that to requests for ranges of resources it has
already partially received; in such a case, a client might well send
an unconditional GET for a range like 10000-15678, believing that to
be from ten-thousandth-and-first to the end of a resource.  Under the
current scheme, if that resource has changed, and the resulting
resource has shrunk to 12388 bytes, the client will be sent bytes
10000 to 12388.  It will then have to re-request the whole entity.
Under my preferred scheme, it would have been sent the whole entity
anyway.
	I also, frankly, worry that some client, despite all of the
available information (including last modified date) will jam the
two ranges together despite all the clues that it is the wrong thing
to do.  This is probably paranoia, but who knows?
	As I said, I am not really interested in forcing the issue
at this late stage, but I remain pretty convinced that the better
(and more conservative) design is the one I've proposed.

				Regards,
					Ted Hardie

Received on Friday, 31 May 1996 16:06:06 UTC