- From: Larry Masinter <masinter@parc.xerox.com>
- Date: Mon, 8 Jan 1996 00:44:43 PST
- To: http-caching@pa.dec.com
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