W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1995

Re: Comments on Byte range draft

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Mon, 13 Nov 95 17:47:01 PST
Message-Id: <9511140147.AA01210@acetes.pa.dec.com>
To: Larry Masinter <masinter@parc.xerox.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
    Wait wait, I keep on saying "if-not-modified-since" and you keep on
    replying "if-modified-since". 
    
I wish that the mailer at cuckoo.hpl.hp.com would simply reject
all future mail containing the string "if-modified-since".

I've argued before that what we really want in HTTP is an
opaque cache-validator string that is provided by the server
with an object, should be kept with any cached copy of an
object, and can be presented to the server to say "is the
object associated with this validator still valid?"

If the server implementor is foolish enough to use a date
for this string, that's not the problem of the HTTP working
group.  

So let me rewrite Larry's message, which he sent as this:

    Normally, GET with caching uses 'if-modified-since', i.e., give me
    the data if it's newer than/different from what I already have.

    However, GET of a byte range need the converse. It's "give me this
    byte range of this object, UNLESS the object is newer
    than/different from what I already have".

    The sense is different. HTTP doesn't have a
    "if-not-modified-since", and would need it if you want byte ranges
    to actually work with data that might change.

using my terminology:

    Normally, GET with caching uses 'Cache-validator: XXXX', i.e., give me
    the data if it's different from what I already have.

    However, GET of a byte range need the converse. It's "give me this
    byte range of this object, UNLESS the object is diffferent from
    what I already have".

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.  Which is to
say, the meaning of the Cache-validator field itself DOES NOT HAVE
TO CHANGE.  The only thing we need to do is to be clear about
what "Request-byte-range" actually means (even if we don't actually
call it by a 60-character name!).

Any use of terms such as "newer" or "since" are just going to confuse
things.

-Jeff
Received on Monday, 13 November 1995 18:00:46 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:35 EDT