Re: First draft of a list of goals

    >Probably I would define "valid" as
    >        What the origin server would provide if it received the
    >        request at approximately this instant.
    
    I don't see how this definition of "valid" would fit in a HTTP caching
    model.  How could a proxy cache ever serve a "valid" copy without
    contacting the origin server?
    
First of all, I do not believe that we are in agreement that an
HTTP caching model requires the cache not to contact the origin
server.  (Sorry about the double negative in that sentence.)

Second, my list of goals did not *require* that correct caching
be employed; it only requires that it be possible.  In particular,
if the server can control whether correct caching is done (that is,
whether the user must see a valid copy of an object or not), then
it has the ability to choose between correctness or performance.
If the protocol, however, does not provide a means for the server
to ensure correctness, then this choice will never be available to
a server administrator.

Finally, my definition (above) of "valid" could include "the server knows
that the object will not change before a certain date, and so can
safely assign a lengthy expiration period."  In the extreme case,
this turns into an "immutable object" model, in which the server
can safely return "Expires: never" (in whatever syntax we agree upon).
For example, RFCs are supposedly immutable once issued, and so
they could be returned with "Expires: never".

    Under the current draft, if a server at time T generates a response on
    URI U which includes an Expires or Cache-control response header,
    
    - this does _not_ mean that the server guarantees that the response
      it will serve for U will not change until some time T+X.
    
    - rather, it means that the server finds it _appropriate_ for clients
      to give the response to a request for U at any time up to T+X.
    
I believe that (1) the current HTTP 1.1 draft is broken with respect
to caching, and (2) this subgroup was formed with the specific purpose
of obtaining consensus about whether it is broken, and if so, how to
fix it.  So I would ask people not to treat the "caching model" implicit
in any existing HTTP 1.x draft as a given.

We can argue later on about whether we can or should change the
meaning of existing syntax (such as "Expires" or "Cache-control");
but we have to agree on a caching model before we can have that
argument.

-Jeff

Received on Wednesday, 27 December 1995 22:12:40 UTC