Re: New Editorial issue MESSAGE-BODY

On Wed, 30 Jul 1997, Jim Gettys wrote:

> In working on the Options specification, Roy and Jeff came across a
> problem in the spec that needed clearification.
> For the record, here is the result.
> 				- Jim
>including the following from Jeff Mogul:

>>  Anyway, I think perhaps the best wording is:
>>       A message-body MUST NOT be included in a request if the
>>       specification of the request method does not allow
>>       sending an entity-body in requests.
>>This means GET, HEAD, and DELETE, right?

Many moons ago we had a discussion about creating a SAFE GET method.
During that discussion it was clear to me that any method which
didn't explictly exclude a request body could include one. IFF the
content-length and/or transfer-coding: chunked was specified.
In other words, for historical reasons, GET couldn't have a body and
there were words to that effect. I didn't specifically look for HEAD
or DELETE so I can't comment now, but I did convince myself that any
other 'modern' method could have a body under HTTP/1.1 because HTTP/1.1
requires an explicitly stated content length. (header or chunked

And it is that explict length which allows proxies, servers, etc. to
sort out the question that Jeff raised. On a persistent connection,
the transaction is bogus if it has a body and doesn't have explict

There is no hope for extensible methods if the rules don't allow content
with unknown methods.

So I think the wording needs to be something like (if this isn't there

   Any request with a method which doesn't explicity exclude a content
   body may include a body. Any request which includes a body MUST
   explictly state the length with either a Content-length: header
   field or Transfer-encoding: chunked.

Dave Morris

Received on Wednesday, 30 July 1997 08:48:53 UTC