Re: Still trying to make sense of HTTP caching model

    > So now the remaining question is "should we add an Xyzzy: header to the
    > HTTP spec?"  No way!  "Expires:" not only solves the problem already,
    > it also is compatible with existing practice, more or less.
    
    It seems to me that this is rather *incompatible* with existing 
    practice.  Take the CERN server, for example.  It is widely used and
    will continue to be for the foreseeable future.  To add an expiration
    date to a document /path/foo the maintainer creates /path/.web/foo.meta
    containing the line "Expires: <date>".  It is up to the maintainer
    who creates it and it is attached, not computed.  I don't know of any
    servers today which compute Expires, as opposed to attaching it.
    As Jeff points out this makes the semantics  of Xyzzy impossible for
    current servers.

There are really two issues here:
(1) current servers do not provide a means to express all four of
the expiration styles that I described.  They can only express #3,
e.g. "Don't let anyone cache this after Dec 11 1995".  You are right
about this, although this is not a failure to *support* the "semantics
of Xyzzy"; this is a failure to *utilize* the full semantics of Xyzzy.

(2) some current servers apparently happen to use the keyword "Expires"
in the foo.meta file to express #3.  The reason I invented the keyword
Xyzzy was precisely to demonstrate that this is irrelevant.  If HTTP 1.1
were to declare that "Expires:" is outlawed and "Xyzzy:" MUST be used
instead, you would no doubt be able to fix the CERN server with less
typing than it took you to compose your last message on this subject!

The uses of the string "Expires:" in the protocol header and the
string "Expires:" in the .meta files on certain servers has to be
decoupled.  We cannot hold the protocol spec hostage to lazy
implementors.  In other words, a server that wants to provide
some other expiration style (such as #1, "The document ceases to exist
on Dec 11 1995") will have to take some action beyond blindly appending
the .meta file to the response headers.  Creating new header fields
just so that server writers won't have to exert even a minimal effort
is a bad idea.

But note that your current CERN server will still be 100% compatible
with the HTTP 1.1 spec; it just won't be able to express any style
except #3 (which is all it can do today, anyway).

-Jeff

Received on Thursday, 7 September 1995 15:38:06 UTC