Re: ADAMS1, point 31. (cachability of methods).

At 17:44 11/16/98 PST, Jeffrey Mogul wrote:

>   Unless specifically constrained by a cache-control (section 14.9)
>   directive, a caching system MAY always store a successful response
>   (see section 13.8) to a GET or HEAD request
>   as a cache entry, MAY return it without validation
>   if it is fresh, and MAY return it after successful validation.
>   A caching system MUST NOT treat responses to other methods
>   as cachable (by the definition in section 1.3) unless the
>   response includes Cache-Control or Expires header fields
>   implying that the response is cachable.

What is the cache allowed do in the following scenario:

client A to proxy:

	FOO / HTTP/1.1
	host: some.host

proxy to origin
	
	FOO / HTTP/1.1
	host: some.host
	via: ...

origin to proxy

	HTTP/1.1 200 OK
	Cache-control: max-age=3600
	...

client B to proxy

	BAR / HTTP/1.1
	host: some.host

Can it return the cached response? Do we need a vary on the method name?
The definition in 1.3 doesn't indicate this.

Regardless, do you agree that the wording conflicts with 13.11:

All methods that might be expected to cause modifications to the origin
server's resources MUST be written through to the origin server. This
currently includes all methods except for GET and HEAD. A cache MUST NOT
reply to such a request from a client before having transmitted the request
to the inbound server, and having received a corresponding response from
the inbound server. This does not prevent a proxy cache from sending a 100
(Continue) response before the inbound server has sent its final reply.

and also with 5.1.1

Servers SHOULD return the status code 405 (Method Not Allowed) if the
method is known by the server but not allowed for the requested resource,
and 501 (Not Implemented) if the method is unrecognized or not implemented
by the server.

where it in 1.3 it is stated how a server at any time can become a tunnel

Server

... Likewise, any server may act as an origin server, proxy, gateway, or
tunnel, switching behavior based on the nature of each request....

in which case it can't be a cache:

Cache

...Any client or server may include a cache, 

Anyway, the reason why I don't think this is a good idea is that *if* a
response is fully cachable regardless of whether the method is understood
or not, then it smell, feels, and looks like a GET request. There is
absolutely no reason to have several GET-alike methods. GET is special
because it is special because it is special.

Note, that this has nothing to do with your cache control extensibility
which I like (and know about) - it just shouldn't be applied to responses
from operations by unknown methods.

A confused? Henrik

>Henrik, please read section 14.9.6 (Cache Control Extensions).
>It already handles the problem you are describing.  For example,
>an extension can define the meaning of a new cache-control
>directive (let's call it "henrik-mode"), and send:
>
>	Cache-control: max-age=0, must-revalidate, henrik-mode=999
>
>Any cache that doesn't understand your extension must ignore
>"henrik-mode" and so will do the necessary revalidation.  If
>the cache does understand your extension, 14.9.6 allows it
>to use the "henrik-mode" directive to modify the behavior
>of the other two ("modify" may mean "ignore").
>
>    I do not believe we at this point can change whether we consider
>    caching or the method to be the highest in the hierarchy.
>
>I don't think at this point we should be proposing changes to
>the HTTP/1.1 protocol without first reading the existing
>specification :-)
>
>-Jeff
>
--
Henrik Frystyk Nielsen,
World Wide Web Consortium
http://www.w3.org/People/Frystyk

Received on Tuesday, 17 November 1998 17:11:56 UTC