I'd like to propose that the wording be clarified in the spec. I have
encountered servers that "accept" a chunked POST with 200 (OK) and then=
silently discard the message body, passing a zero-length entity-body to=
service layer (CGI or servlet), so I think some implementors are
misinterpreting the current wording.
I propose adding something along these lines:
"If a server disallows message bodies encoded with the chunked
transfer-coding in requests to some resource, it MUST return an error c=
in the response to such requests. If this is the primary reason for
rejecting a request, the response MUST contain the 411 (Length Required=
Also, this sentence should be reworded:
Section 4.4, Message Length:
All HTTP/1.1 applications that receive entities MUST accept the =93chun=
transfer-coding (section 3.6), thus allowing this mechanism to be used =
messages when the message length cannot be determined in advance.
becomes something like:
All HTTP/1.1 applications that receive entities MUST understand the
=93chunked=94 transfer-coding (section 3.6), thus allowing this mechani=
sm to be
used for messages when the message length cannot be determined in advan=
This does NOT mean that servers must accept messages containing bodies
encoded with the chunked transfer-coding.
"Roy T. Fielding" <firstname.lastname@example.org> on 01/22/99 10:54:56 AM
To: Carl Kugler/Boulder/IBM
cc: email@example.com, firstname.lastname@example.org
Subject: Re: Resend: Re: IPP> Chunked POST: SUMMARY
Content-type: text/plain; charset=us-ascii
>The IPP WG would really like clarification on this point: Is the intent
>the HTTP/1.1 spec to say that an HTTP/1.1 server MAY reject any request
>without a defined Content-Length? This would imply that a conformant
>HTTP/1.1 server MAY reject any request with the "chunked" transfer-coding.
Yes. A conformant HTTP/1.1 server MAY reject any request for any reason,
just one of them being 411 Length Required. There would be no reason to
define 411 if it could never be used by a conformant server. The wording
in the spec is poor -- it should have said that an HTTP/1.1 application
is required to understand the "chunked" transfer-coding, not accept it,
since it is referring to message parsing and not the response status.
Why is this necessary? Because an Internet protocol cannot require a
server to accept denial of service attacks.