Re: First draft of a list of goals

Jeffrey Mogul:
[...]
>    [Koen Holtman:]
>    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.

Reading your message, I get the impression that you want to extend the
protocol to allow caches to contain not only

 a) responses that are still fresh, but maybe not not original anymore

but also

 b) responses that are known to be still original.

(I am using:
        original -- exactly what the origin server would say
        fresh -- within the lifetime granted by the origin
                server. (=un-expired under HTTP 1.1)

Maybe we need an additional new word to denote `known to be original'.
)

I would have no problem with a protocol that allows caches to contain
both a) and b) types of responses.  Allowing b) would mean the
introduction of a new Cache-Control directive

    "response-same" "=" delta-seconds 

(we can argue about the name later) that would allow the server to
express that it will produce exactly the same entity body for that
request for at least N seconds (some particular response headers
headers, like Date and Cache-control, could change during that time
though).

> So I would ask people not to treat the "caching model" implicit
>in any existing HTTP 1.x draft as a given.

OK.  I do feel however that we need to take the "caching model"
implicit in the 1.1 draft as a starting point of our model.

>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.

I am very much against changing the meaning of existing syntax at all,
even after we have a model.  For new or different functionality, we
should introduce new syntax (like I did above), not change the
semantics of existing constructs.

If we change the semantics of existing constructs, things will get
extremely confusing (Which Expires header do you mean is broken? The
old one or the proposed one?).

Proposing new syntax and semantics may be the best way to add pieces
to our model until we agree on it.  I say this from my experience with
formal systems: at a certain level of complexity, you need a formalism
to capture all details of your model, and the only formal system we
share is the system for defining HTTP header semantics.

>-Jeff

Koen.

Received on Thursday, 28 December 1995 22:58:13 UTC