- From: Alex Rousskov <rousskov@measurement-factory.com>
- Date: Fri, 30 Apr 2004 15:55:41 -0600 (MDT)
- To: Lisa Dusseault <lisa@osafoundation.org>
- Cc: HTTP working group <ietf-http-wg@w3.org>
On Fri, 30 Apr 2004, Lisa Dusseault wrote: > RFC2616, section 7.2.1 only requires Content-Type for entity bodies, > not for other non-entity request bodies: > > When an entity-body is included with a message, the data type of that > body is determined via the header fields Content-Type and Content- > Encoding. The above is not really a requirement. Content-Type is not a REQUIRED header. Content-Encoding is only needed for encoded content. The presence and transfer-length of request body is determined according to these rules (see Section 4.4 for details, subject to errata): 2.If a Transfer-Encoding header field (section 14.41) is present ... then the transfer-length is defined by use of the "chunked" transfer-coding (section 3.6) 3.If a Content-Length header field (section 14.13) is present, its decimal value in OCTETs represents both the entity-length and the transfer-length. 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. There are other related MUSTs. > WebDAV seems to have interpreted this requirement more broadly, as > if it were worded "When a body is included with a message, ..." For > example, PROPFIND requests contain a body that is not an entity > body, but instead additional command detail. IMO, any body is "entity body" from HTTP point of view. There are just different entities being embodied. > One compromise is to include Content-Type with a reasonably > appropriate MIME type, but one that doesn't need to specify the diff > format used. > > PATCH /file.txt HTTP/1.1 > Host: foo > If-Match: "def" > Content-encoding: gzip > IM: gdiff > Content-Type: application/octet-stream As far as I can see, the above request will not be handled correctly by intermediaries (they will drop its body). You need either Content-Length or Transfer-Encoding header. HTH, Alex.
Received on Friday, 30 April 2004 17:55:44 UTC