- From: David W. Morris <dwm@xpasc.com>
- Date: Wed, 30 Jul 1997 08:43:52 -0700 (PDT)
- To: Jim Gettys <jg@pa.dec.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
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 encoding). 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 length. 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 already): 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