Re: i19 Bodies on GET (and other) requests

On Jan 16, 2007, at 6:09 PM, Mark Nottingham wrote:
> Are you saying that a cache on such a proxy or gateway SHOULD NOT  
> return a fresh response from cache, but instead forward the  
> request, if a GET request has a message-body?

No.  A cache does not "return" and does not "forward".  You aren't using
the definitions as stated in the specification.

    cache
       A program's local store of response messages and the subsystem
       that controls its message storage, retrieval, and deletion. A
       cache stores cacheable responses in order to reduce the response
       time and network bandwidth consumption on future, equivalent
       requests. Any client or server may include a cache, though a  
cache
       cannot be used by a server that is acting as a tunnel.

You are assuming that a cache is a server because that is how the term
is often used in our line of work.  That is fairly common, and you are
right that 2616 has several places where the word cache is misused.
What I suggested was:

   When a request message contains both a message-body of non-zero
   length and a method that does not define any semantics for that
   request message-body, then an origin server SHOULD either ignore
   the message-body or respond with an appropriate error message
   (e.g., 413).  A proxy or gateway, when presented the same request,
   SHOULD either forward the request inbound with the message-body or
   ignore the message-body when determining a response.

Note that a proxy or gateway "SHOULD either forward ... or ignore".
That entirely covers all possible combinations of server, with or
without cache, and without the contradictions that were added to 2616.
When a proxy or gateway uses a cache, it is "determining a response".
We could add "determining a response though use of an internal
cache and/or configurable error mechanism", but then we would be
making a guess about the scope of ways in which a proxy or gateway
might be implemented, rather than specifying an HTTP interface
requirement.

....Roy

Received on Wednesday, 17 January 2007 02:52:29 UTC