W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1995

Re: Cacheable extension methods (was: an idempotent idea)

From: Shel Kaphan <sjk@amazon.com>
Date: Mon, 11 Sep 1995 13:01:01 -0700
Message-Id: <199509112001.NAA08803@bert.amazon.com>
To: Larry Masinter <masinter@parc.xerox.com>
Cc: fielding@beach.w3.org, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Larry Masinter writes:
 > Of course, proxies have to understand the semantics of <method> and
 > <httpversion> in order to do CACHING. Yes, you need to know what
 > someone really intended before you start saving away the response and
 > feeding it back to clients later.

It would be nice to get this clarified.  What specifically is wrong
with this model: *Most* of the time the header metadata (not counting
the method) will contain enough information to make caching decisions.
On requests, all standard HTTP methods must be forwarded to the origin
server, with the exception of GET and HEAD, which may be served from a
cache (depending on other headers and the state of the cache).  This
special rule for GET and HEAD is, I think, the only place where
proxies have to know the semantics of the methods for cache control
purposes.  (And generalizing this is why I thought it would be useful
to have another header to cause this behavior for non-standard
methods).  Certainly if the proxy is acting as a protocol gateway the
methods also must be understood, and can't be forwarded if there is no
pre-established mapping.  Whether or not to pay attention to
other headers such as "Pragma: no-cache" or "Cache-control: ..." is
another version-dependent decision, but is independent of the method.

On responses, I believe that whether or not there is an entity
suitable for caching can be completely controlled by the response
header information.  Whether it in fact *is* controlled this way in
current practice is a different matter.  In current practice, only
POST is really in question.  And I know for a fact that some major UAs
cache results the same way whether they are results of GET or POST --
in fact the results occupy the same cache slot (which I think is
good, even if only serendipitous).

You agreed that proxies can forward all methods.  But you said that
they need to understand the method semantics to properly handle
caching.  I think that the safe behavior is that if proxies don't
recognize the request method they must forward it toward the origin
server.  I am looking for reasoned arguments on why the response must
not be cached when the method is unknown.

This all gets back to the same old unanswered questions about the
semantic requirements on the behavior of caches.
Received on Monday, 11 September 1995 13:07:09 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:15 UTC