- From: Roy T. Fielding <fielding@apache.org>
- Date: Tue, 20 Aug 2002 14:44:08 -0700
- To: Jeffrey Mogul <Jeff.Mogul@hp.com>
- Cc: "'Alex Rousskov'" <rousskov@measurement-factory.com>, "'Kim Horne'" <kim@pookzilla.com>, <ietf-http-wg@w3.org>
>> Probably if the example had included an explicit Content-length
>> field in the first group of headers, the ambiguity would go
>> away, but I think the Message Length rules (section 4.4) don't
>> require that.
>
> Roy Fielding writes:
>
> There is no ambiguity. No content-length in a request means length ==
> 0.
>
> My mistake. I must have missed the part of RFC2616 that says
> this. In fact, I still can't find it; perhaps you could point
> out the specific normative language?
Section 4.3 of RFC 2068 says
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 MAY be included in a
request only when the request method (section 5.1.1) allows an
entity-body.
and in RFC 2616 it says
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.
In both cases, the first sentence is unambiguous. The example you gave
had neither Content-Length nor Transfer-Encoding.
....Roy
Received on Tuesday, 20 August 2002 18:00:42 UTC