Re: i19 Bodies on GET (and other) requests

On 2007/01/17, at 2:56 AM, Scott Lawrence wrote:

>
> On Tue, 2007-01-16 at 10:16 +1100, Mark Nottingham wrote:
>> This is fairly clear upon a careful reading of 4.3;
>>
>>> The presence of a message-body in a request is signaled by the
>>> inclusion of a Content-Length or Transfer-Encoding header field in
>>> the request's message-headers. A message-body MUST NOT be included
>>> in a request if the specification of the request method (section
>>> 5.1.1) does not allow sending an entity-body in requests. 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, then the message-body SHOULD be ignored when handling the
>>> request.
>
>> However, I think casual readers -- and some implementers -- have been
>> tripped up because many method definitions are silent on the matter,
>> and don't *explicitly* allow sending an entity-body. It might be
>> clarified by changing "does not allow" to "explicitly disallows".
>
> This is a general problem: some people want everything spelled out in
> every possible place where it might be relevant, others would prefer
> that each statement be made only once so that the spec is as short as
> possible but you must read all of it to understand it.  I'm  
> strongly in
> the latter camp.

FWIW, I'm pretty strongly in it as well, provided that it's  
relatively easy to find the relevant portion of the spec.

>   From my point of view, the current spec is too long by
> at least half, and the repetition of some rules in some places  
> leads the
> unwise to assume that if that rule was repeated here and wasn't  
> repeated
> there, then it must not apply there...

OK, but the proposal reduces the number of words in the spec by one,  
and increases the number of characters by six... surely you're not  
concerned to that degree?

>> Also, devil's advocate;
>> 1) What are the implications of an entity-body on GET for the caching
>> model? The spec is silent on this AFAICT.
>
> Again - the spec has clear mechanisms for providing explicit cache
> controls - they should be used, and nothing should be inferred that  
> they
> do not make explicit.  IMHO, any cache should assume that any response
> is not cachable unless told that it is.

I strongly agree with the sentiment, but heuristic freshness *is*  
explicitly allowed.

However, my question was more to how, if at all, a request entity  
body on GET affects a cache's operation when the response is clearly  
cacheable; e.g.,

C: GET http://example.com/foo HTTP/1.1
C: Content-Length: nnn
C: Content-Type: application/xml
C:
C: <?xml version="1.0" encoding="utf-8"?>
C: <thing>I am a request entity body, hear me roar.</thing>

S: HTTP/1.1 200 OK
S: Content-Length: nnn
S: Content-Type: application/xml
S: Cache-Control: max-age=600
S:
S: <?xml version="1.0" encoding="utf-8"?>
S: <thing>And I'm a response entity body.</thing>

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.

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."

>> 3) Are there any existent origin server or intermediary
>> implementations that are fully conformant with this requirement?
>
> Which requirement?

... that "A server SHOULD read and forward a message-body on any  
request".

Cheers,

--
Mark Nottingham     http://www.mnot.net/

Received on Tuesday, 16 January 2007 22:49:02 UTC