Re: i19 Bodies on GET (and other) requests

On Jan 16, 2007, at 2:49 PM, Mark Nottingham wrote:
> My reading is that this would be cacheable, and that the cache key  
> would be just the URI. In particular, the last sentence of the  
> quoted spec text above helps clarify this, although it's talking  
> about servers, not necessarily caches.

Don't get the terminology messed up.  Caches are storage things that
could be on either clients or servers.  Servers are components that
happen to be playing the role of sending a response at this moment.
As such, the only thing it should talk about is servers -- whether
or not a cache exists in the server is irrelevant.

> Does that make sense? I'd feel a bit better if the language were  
> massaged to include not just servers, but caches as well. E.g.,
>
> "A server SHOULD read and forward a message-body on any request. If  
> the request method does not include defined semantics for an entity- 
> body, or if the request method is unrecognised, then the message- 
> body SHOULD be ignored by servers and caches when handling the  
> request."

I disagree with both sentences.  The first one is just wrong -- it
contradicts both the rules for message parsing (fails to account for
HEAD requests) and lumps all servers into the category of proxies
and gateways.  In the second sentence, caches do not "handle the  
request",
ever.  The cache is part of the server and subject to its requirements.

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.

....Roy

Received on Tuesday, 16 January 2007 23:21:07 UTC