RE: Caching the results of POSTs and PUTs

Paul Leach writes:
 > 
 > 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).
 > 

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

 > In both cases, there are Expires: and Cache-Control: max-age headers 
 > from the response kept with the cached data. In case 1, I agree with 
 > the suggestion for Cache-Control: no-side-effects being required in the 
 > response in order to make the entry in the cache.
 > 
 > In case 1, subsequent POSTs with the same Request-URI and 
 > Request-entity-body can be satisfied from the cache, if the cached 
 > entity is still fresh.  A GET with that Request-URI can *not* be served 
 > from the cache entry with this key. (Although it could be served from 
 > an entry created via a prior GET of this Request-URI.)
 > 
 > In case 2, subsequent GETs with Request-URI the same as the 
 > Location-URI can be served from the cache (if the cached entity is 
 > still fresh).  Subsequent POSTs can not be served from the entry with this key.

Let me avoid addressing some specific points above by simply stating
that I think the key should always be case 3, if there is a Location URI
present in the response.  Otherwise, the only GET request that could match any
POST response in the cache would be if the POST had a null request-entity-body.

If there is a non-null request-entity-body and no Location header in a
cache entry, then no subsequent GET can be responded to using this
cache entry.  However, if Cache-control: no-side-effects was set for
this entry, then subsequent POSTs could responded to using this entry.
So cache-control: no-side-effects doesn't control whether the response
is stored into the cache -- that's entirely up to the "freshness"
headers.

You should not interpret the combination of no Location header + no
cache-control:no-side-effects header to mean there is no point storing
the response in the cache, as a later conditional POST (POST with
response cache-validator) might use the cached response even though
the request went through to the origin server.

I'm claiming that you really need to use the request-entity-body as
part of the cache key, so your case 2 should not occur unless there is
no request-entity-body, in which case any POST that matches that could
be served by that cache entry.

 > 
 > ]
 > ] In either case, caching follows the same rules as for GET responses:
 > ] the server provides a fresh-until time, and the cache must validate
 > ] non-fresh entries with the origin server.
 > ]
 > ] Validation could be done using a conditional POST.  A conditional POST
 > ] has the same form as a normal POST (including the entire entity body),
 > ] but includes the cache-validator returned by the server in its earlier
 > ] response.  The meaning of a conditional POST is "look at the URI,
 > ] entity body, and validator in this request: if you would give me
 > ] the exact same response as you gave before, including the same
 > ] validator, then just tell me '304 Not Modified'; otherwise, do a
 > ] normal POST for me."
 > 
Yes, and do the same side effects in any case.

--Shel

Received on Saturday, 6 January 1996 01:43:15 UTC