- From: Shel Kaphan <sjk@amazon.com>
- Date: Sat, 6 Jan 1996 16:56:28 -0800
- To: dwm@shell.portal.com
- Cc: http-caching@pa.dec.com
Dave Morris: On Sat, 6 Jan 1996, Shel Kaphan wrote: [...] > > - For POSTs where the response does not contain Cache-control:no-side-effects, > the response cannot be used to answer any POSTs. As I tried to say a few minutes ago in another message, it seems to me that a third POST case exists ... the POST result is cachable BUT the server must see the request and perhaps pick one of N responses. You're right - I wasn't being clear. A conditional POST could indeed make use of such a cached result, if the origin server returned 304. [...] > - 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. Dave Morris 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. Saves a redirection, which in today's world can't be trusted to contact the origin server on the second request anyway. I certainly want to have the ability to follow a POST with a later GET and get what the POST returned. 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. 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. --Shel
Received on Sunday, 7 January 1996 01:12:31 UTC