- 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