RE: Caching the results of POSTs and PUTs

I want to apologize in advance to not having studied all of the
http-caching mail -- I've been a little swamped, and I've really only
skimmed it. So perhaps this is out of date or confused, but...

================================================================
Paul Leach wrote:
 > There are two cases of caching for POST that I can identify:
 > 1. The cache key is (Request-URI, Request-entity-body)
 > 2. The cache key is (Location-URI) from the response (modulo the 
 > spoofing issue).
and Shel added:
> What about case 3:  the cache key is
> 	(Request-URI, Request-entity-body, Location-URI)
> (BTW I also think the key for GETs should be (Request-URI, Location-URI)).
================================================================
Isn't the 'Location-URI' some kind of red herring? If I ask for
'foo.com' and you respond with a new Location header, I should *still*
have a cache entry for the original request, no?

I want to separate out the questions:

a) What is the cache key for a request?
b) What other cache entries might be generated by a response?
c) What other cache entries might be invalidated by a request or
   response?
d) What presumption in lieu of a cache-control method might be made as
   to the cachability of a request at all.

The cache key for a request is always a subset of the request
(including method, all of the headers and entity body); it is exactly
the subset that the response might be considered to vary by. We
presume that the response varies by Authentication and State
information, and we assume that the response does NOT vary by Accept
headers unless the response includes some indication of that variance.

In addition, we have some rules for some of the other methods:
- a successful PUT on a URL should invalidate all other entries for the
  same location (c), and may create a cache entry of GET on the same
  location.

- a POST on a location might invalidate a GET entry on the same
  location.

- HEAD can be computed from GET caches with the same varying nature.

- a Location: header in a response should either create a new cache
  entry for GET of that Location with no other headers in the cache
  key (state, authenticator, etc.) or at least invalidate any cache
  for GET of that Location (depending on whether the cache trusts
  the location).

Received on Monday, 8 January 1996 08:58:50 UTC