Re: First draft of a list of goals

Jeffrey Mogul:
>
>        [Koen Holtman:]
>        "response-same" "=" delta-seconds 
[...]
>This is not the only possible approach.  I've started to write
>up my proposed design in detail, so perhaps I should wait to explain
>it further.

I will wait for your proposed design.

>    > 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.
>    
>Would someone like to define what this is?  I'm happy to include
>this as one of the design alternatives, but it's pointless to
>treat it as an alternative as long as there is no explicit
>description.

I have argued before that the best way for us to describe a caching
model is by specifying the headers involved.  This is exactly what the
1.1 draft does for the 1.1 caching model.  You cannot just discard the
1.1 caching semantics as an alternative just because the description
is `implicit' (whatever that means).

I fear that a complete and accurate `explicit' description of the 1.1
caching model would require more math than we share.

>I most certainly do not believe we can treat it as both implicit
>and sacred at the same time.

Look, all I'm asking is that you
 1) do not use the word `expires' in a way that conflicts with its
    use in the 1.x drafts
 2) do not discard the caching functionality already defined in 
    the 1.1 draft just because it does not have an `explicit model'.


For what it is worth, here is my try at an explicit model for 1.1
caching.  I don't think it is any more clear than the `implicit'
description in the draft.

 - the HTTP 1.1 caching model allows for the situation that an
   URI U binds, at any point T in time, to multiple, different
   responses `stored somewhere inside the web' (i.e. either at the
   origin server or in a cache)'.  Mechanisms such as Expires,
   Cache-control, and conditional GETs control this binding of a
   particular response to an URI through time.

 - a request for an URI U through a proxy should be seen as the
   request to serve one of these bound responses.  If a proxy knows of
   multiple different responses bound to U at time T, it must serve
   the response with the latest date header.

 - as long as response to URI U in a cache is not expired, it is bound
   to the URI U.

 - if a response in a cache is expired, it is no longer bound to U,
   and may thus not be served by the cache anymore.  However, a cache
   may re-establish the binding of the response to U by doing a
   conditional GET on U and getting a `not modified' response.

 - more mathematically speaking, this binding is a function

      web-bind:  (METHOD, URI, request-headers, Time)  -->
                                        Set of Response

   and a request with method M, URI U, and request headers R done to a
   proxy at time T will return one of the bound responses R:

     if 
         proxy-response(M, U, RH, T) = R
     then
         R `is an element of the set' web-bind(M, U, RH, T).


>-Jeff

Koen.

Received on Friday, 29 December 1995 16:19:36 UTC