Re: i19 Bodies on GET (and other) requests

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

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.
2) Ditto for content negotiation.
3) Are there any existent origin server or intermediary  
implementations that are fully conformant with this requirement?

Cheers,


On 2007/01/16, at 9:50 AM, Roy T. Fielding wrote:

>
> On Jan 15, 2007, at 5:34 AM, Scott Lawrence wrote:
>> On Mon, 2007-01-15 at 17:35 +1100, Mark Nottingham wrote:
>>> Background at:
>>
>>> <http://lists.w3.org/Archives/Public/ietf-http-wg/2006AprJun/0103>
>>>
>>> Does anybody have any new information / thoughts about this?
>>
>> It seems to me that inferring anything about the presence or  
>> absence of
>> a body based on the method only creates ambiguous situations when  
>> that
>> inference is in conflict with the explicit indications already  
>> defined
>> by the protocol (the Content* and Transfer* headers).
>
> Right, it would just create contradictions where none are necessary.
>
>> The only exception to this should be HEAD.  In retrospect, I think  
>> that
>> HEAD should have defined special headers to express what would  
>> have been
>> in the body descriptors so that there was no ambiguity
>> (head-content-length would have the value that would have been in
>> content-length if the method had been GET, etc).
>
> Heh, we realized way back in 1994 that HEAD should have been defined
> to return a body containing the GET-headers, but even back then it was
> way too late to fix that weirdness.  At the time, content-length was
> just advisory (for the progress bar) anyway, so it was actually a
> significant change to the message semantics to enable persistent
> connections work at all over HTTP/1.x.
>
> It is absolutely critical that the algorithm for determining the
> presence or absence of a body have no dependence whatsoever on the
> semantics of the method (aside from HEAD).  Failure to sustain that
> design would mean that all proxies must block all new methods.
>
> ....Roy
>


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

Received on Monday, 15 January 2007 23:16:01 UTC