W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2007

Re: i19 Bodies on GET (and other) requests

From: Scott Lawrence <scott@skrb.org>
Date: Tue, 16 Jan 2007 10:56:49 -0500
To: Mark Nottingham <mnot@mnot.net>
Cc: "Roy T.Fielding" <fielding@gbiv.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Message-Id: <1168963009.2935.15.camel@sukothai.pingtel.com>

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

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

> 2) Ditto for content negotiation.
> 3) Are there any existent origin server or intermediary  
> implementations that are fully conformant with this requirement?

Which requirement?

-- 
Scott Lawrence
http://skrb.org/scott/
Received on Tuesday, 16 January 2007 15:57:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:00 GMT