- From: Shel Kaphan <sjk@amazon.com>
- Date: Fri, 5 Jan 1996 17:23:50 -0800
- To: Paul Leach <paulle@microsoft.com>
- Cc: mogul@pa.dec.com, http-caching@pa.dec.com
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