Re: cache keys

Shel Kaphan:
>
>Dave Morris:
>[...]
>  On Sat, 6 Jan 1996, Shel Kaphan wrote:
>  [...]
>  > - What about the HTTP method?  I do not believe that the HTTP method
>  > should be part of the cache key.  In fact, I think it can't be.
>
>  I don't think I agree. I'm inclined to believe it must be part of
>  the key. There is nothing in current practice that I'm aware of 
>  which wouldn't allow GET of a URI to return a price list and POST 
>  of the same URI to confirm the order.

I agree with Dave that the method must be part of the cache key.

>I do that all the time (use the same URI for POSTs and GETs), just to
>get around cache problems when different kinds of requests need to
>return new versions of the same object. 

I also do it all the time, mainly to allow reload buttons on some
browsers to work as expected.  But my POSTs will not necessarily yield
the same result as subsequent GETs on the URI, they can also give an
error message in a 200 response, leaving the content bound to the GET
unchanged.

> Saves a redirection, which in
>today's world can't be trusted to contact the origin server on the
>second request anyway.

Redirection also cannot be trusted?  Ack!  I wonder what you can trust
these days.  Can you give an example of a client or proxy that caches
redirects?

>I certainly want to have the ability to follow a POST with a later GET and
>get what the POST returned.

You have it now, by making the GET response always expire immediately.
Modulo browsers that don't care about Expires, of course.

>  In addition, I want the response from that
>POST to make it impossible for me to receive the previous version of
>that object that may have been already in the cache, when I do a later GET.

That is a valid thing to want, but you cannot get it by throwing the
request method out of the cache key.  Too many things would break.

>To me, insisting that each method have its own cache slot for a given
>URI would be analogous to designing a computer cache where LOADs and
>STOREs didn't share cache slots for the same memory locations.

Many POSTs do not act as STOREs.

The 1.1 draft already provides `see other redirection' for POSTSs that
do act as a STOREs.  If implementations of this are broken, they need
to be fixed.  Speccing an new alternative scheme, and hoping that
implementations of that new scheme will be less broken, holds little
promise as a fix.

If you want to propose some alternative scheme to `see other
redirection', the only possible justification can be that this
alternative scheme is more efficient, for example because it avoids
the conditional GETs on every request that are needed in the `see
other' method.

[From here on, I am speculating on how to improve on `see other']

Improving on `see other redirection' can be tricky.  A scheme that
lets POST responses influence cached responses of earlier GETs can
only work as long as all GETs and POSTs travel through the same cache.
If the user agent sends POSTs directly to the origin server, and GETs
though a proxy cache, then the proxy cache has no chance of
invalidating the GET response.  And didn't AOL use a scheme in which
their browsers randomly access one of several proxies for subsequent
requests?

The only thing we can really require as far as request routing is
concerned, is that if a 1.1 browser has an internal cache, then all
GETs and POSTs must go through that cache.  So I get to the following
design:

There must be some way to say

 Cache-control: max-age-for-browser-caches=X,
                proxy-caches-must-always-do-conditional-GETs

in 1.1 responses.  (We can already say something slightly less
efficient: Cache-control: max-age=X, private.)  A server wanting to
use the `POST response replaces old GET responses that are not stale
yet' mechanism on an URI U must send this Cache-control information in
every GET response on U.  Further, we require from browsers that

 If a 1.1 internal browser cache has stored a GET response GR on URI
 U, and it relays a POST response PR from URI U containing the response
 header Location: U ,
 then the cache must either invalidate the old GET response GR or
 (highly preferred) replace it with the POST response PR.

Shel, would this be acceptable to you?  I for one would like to have this
kind of behavior, it would allow my own web software to be a bit more
cache-friendly.  Spoofing problems would be virtually absent in the
above scheme.

But I wonder if this scheme isn't too complicated.  If we spec all
this, what are the chances that everybody will get it right?

>--Shel

Koen.

Received on Sunday, 7 January 1996 15:58:09 UTC