W3C home > Mailing lists > Public > http-caching-historical@w3.org > January 1996

Re: cache keys

From: Shel Kaphan <sjk@amazon.com>
Date: Sat, 6 Jan 1996 16:56:28 -0800
Message-Id: <199601070056.QAA07511@bert.amazon.com>
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.

Received on Sunday, 7 January 1996 01:12:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:55:57 UTC