Re: Request methods that allow an entity-body

On fre, 2007-11-30 at 14:16 +1300, Adrien de Croy wrote:
>  If any 
> message is to have an entity body, it must have a non-zero 
> Content-Length header, or a Transfer-Encoding header.

That rule is for requests messages only, and is all there is to request
parsing for determining if there is a body or not.

For responses the rules are much broader for legacy reasons with
HTTP/1.0 & 0.9.. covered by the next paragraph in 4.3 Message Body.

Regarding request bodies and GET/HEAD/DELETE I think most have settled
to accept what the specs currently says. Request-bodies technically
being allowed but their meaning unspecified in those methods.

The specification as written is quite specific on the subject, but
people do get confused as the semantic meaning of a request body is
unspecified for GET/HEAD/DELETE.

  - As already indicated the request message parsing rules for
deretmining if there is a request body is simply

   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.

  - So is the handling any such request body even when unspecified by
the method.

   if the request method
   does not include defined semantics for an entity-body, then the
   message-body SHOULD be ignored when handling the request.

  - And forwarding of such body by proxies & servers to the processing
agent

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


All quotes from 4.3 Message Body


Now this is how recipients should process the message. Not how the
client may compose the message. 

I am all for extending the specifications of GET/HEAD/DELETE to include
a SHOULD NOT


   Requests sent using this method SHOULD NOT include a request body.


Regards
Henrik