Byte ranges (was Re: Logic Bag concerns)

    I could live with this.  But I worrly a little about the clarity.
    Compare
    
	    GET /foo
	    Range: bytes=30-80
	    Cache-validator: XYZZY
    and
	    GET /foo
	    Cache-validator: XYZZY
    
    In the first case the server honors the the (range) request only if
    the validator is XYZZY; in the second it honors the request only if
    the validator is NOT XYZZY.
	
Dear me.  I believe there is still some confusion, implied by
your use of the phrase "honors the request" for both "GET" and
"Range:".  Range: is not a request; it is a modifier to the GET
request (method).

Consider the case when the Range: header is NOT included.  Then
	GET /foo
	Cache-validator: XYZZY
means
	if the cache-validator for /foo is XYZZY
	then
	    send me nothing	/* Valid case */
	else
	    send me /foo	/* Invalid case */

Now, what does "Range:" mean?  
	GET /foo
	Range: bytes=30-80
	Cache-validator: XYZZY
means
	if the cache-validator for /foo is XYZZY
	then
	    send me bytes 30-80	/* Valid case */
	else
	    send me /foo	/* Invalid case */

In other words, IN ALL CASES what the cache-validator means is
that if it doesn't match, send the whole object.  What Range:
modifies is the behavior of GET when the cache-validator does
match.  And (if you like) you can think of a missing Range:
header as implying "Range: bytes=0-0", so there is really only
one meaning.

Maybe it's simpler to think about this if you pronounce
"GET" as "Make sure my cache for this object is up to date".

Then Range: doesn't affect whether the server honors this
request or not, it simply tells the server "Oh, by the
way, I know that this part of my cached copy is missing."

Your proposal for having separate "If-Cache-Valid:" and "If-Cache-Stale:"
headers worries me.  For example, this would be syntactically valid:
	GET /foo
	Range: bytes=30-80
	If-Cache-Stale: XYZZY
but semantically it seems like a bad idea: "if my cached copy is
bad, then send me only part of a replacement".  I sure hope nobody
thinks this is a good idea!

    You are correct that this isn't strictly necessary.  But remember it
    is only the validator we want to be opaque, not the header :)
    
HTTP headers are not meant to be read by humans, I hope.  (Well,
OK, I suppose I consider server and browser programmers human;
at least some of them have cute little baby daughters.)  So clarity
is important for the specification, but isn't really important
for the header syntax.  What matters instead is how complicated
it is to implement software that uses the syntax.

This is a lesson that CPU architects learned in the 1980s.  Don't
design the instruction set to make it easy to write assembly code
by hand; design it to make it easy to implement fast CPUs.  There
will always be a few maniacs who are willing to write compilers
for the rest of us to use.

-Jeff

Received on Friday, 1 December 1995 11:37:40 UTC