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

Henrik writes:
    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.
    
First of all, the *definition* of "cachable" in 1.3 has nothing
to do with the *specification* of what the proxy is supposed to
do.  So I'll ignore that part of your question, rather than trying
to guess what you really meant.

Second, I see what you mean about the need to match the method
name, since otherwise I think we're in dangerously undefined
territory.  So I guess that sentence I added should become

       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, and the subsequent
       request uses the same method as the request that generated
       the response.

Note that the preceding sentence basically includes the usual
exception to the method-matching rule (GET and HEAD "match")
with the implicit understanding that a cache can't take a HEAD
response and give it back for a new GET request.  Do we need
to make this explicit, too?

    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.
    
Well, I could try to wriggle out of this one, but I admit that this is
a little flakey.  After all, the MUST applies with the precondition
"that might be expected to cause modifications", and perhaps it's
reasonable that if the cached response with the same method has
a non-zero max-age value, then the method shouldn't be expected
to cause modifications.  But the second sentence does contradict this.

So I would change this to:

    All requests 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 other than GET and
    HEAD, unless the request (including its method) matches a cached
    response that includes Cache-Control or Expires header fields
    implying that the response is cachable.
    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.

I can guess that Jim is probably getting itchy.

    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,

If you interpret SHOULD as MUST.  I don't.  Since I wasn't involved
in writing 5.1.1, I'm not sure whether it really meant to say
MUST (or if the word "server" here really includes "proxy").
    
    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.

I think the point is that if an origin server wants to make the
response to a FOO cachable, why should we try to forbid it?
As long as we do it in a way that can't be misconstrued.  If
your origin server doesn't want a proxy to cache a response
to a FOO method, then why on earth is it sending "max-age=3600"?
Just leave that out, and nobody gets hurt.

But if this is all too much for a last-minute change, then I
propose resolving ADAMS31 by not changing anything (relative
to -rev-05).  I started down this path by complaining about
Jim's proposed change in
   http://www.ics.uci.edu/pub/ietf/http/hypermail/1998q4/0142.html
and trying to put his words in the right part of the document.
I suspect we will survive if we just leave this part of -rev-05 alone.

-Jeff

Received on Tuesday, 17 November 1998 18:08:38 UTC