Re: Comments on Byte range draft

Jeffrey Mogul writes:
	...
 > 
 > Which implies that the byte-range header should be named
 > 
 > 	Request-byte-range-if-cache-valid-else-transmit-whole-file: 1-3
 > 
 > when presented along with a Cache-validator: header.

I am with you in spirit, as I *much* prefer this kind of validation
to date comparisons,  but there's something wrong with these names
for this purpose.  (Something besides the length, that is).
There is no "cache" to be valid, so perhaps what you really mean is

Request-byte-range-if-cache-validator-would-still-apply-to-the-requested-document-if-it-were-cached:

But seriously, I doubt http-wg is going to get consensus on this,
given the lack of discussion last time these issues were brought up,
which is why I wanted just the *option* of a "checksum" somewhere in
this mechanism.  But it's true that calling it a checksum means it
should be ... a checksum ... so calling it something more general like
"validator" would be better.

I like the parameterized version of this:

Request-range:	bytes=X-Y; validator=<xxxxx>; other-parameter=<yyyy>

I propose, then, that we choose a set of parameters that can be in this
header, and

(1) that each parameter name be the same as the name of some header
actually received from the server when the initial document fragment was
fetched (without byterange request), and

(2) that these parameters be allowed to include (without limitation)
last-modified, content-MD5, and content-length, the intent being that
any parameter in this header is intended to help the server assess the
validity of the request w.r.t. the available document, and

(optional) (3) we extend the set of headers to include the
generalization "validator" which might be used to contain (e.g.) a
date, filesize, hash, checksum, or random number chosen by the server
as pertaining to a unique version of the document, and allow
"validator=<xxxxx>" to appear as a header in server responses as well
as in this header.

If we can agree to (3) then maybe later we can also think about using
this in other appropriate places.


--Shel

Received on Monday, 13 November 1995 19:05:49 UTC