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 the
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 code
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 “chunked”
transfer-coding (section 3.6), thus allowing this mechanism to be used for
messages when the message length cannot be determined in advance.
becomes something like:
All HTTP/1.1 applications that receive entities MUST understand the
“chunked” transfer-coding (section 3.6), thus allowing this mechanism to be
used for messages when the message length cannot be determined in advance.
This does NOT mean that servers must accept messages containing bodies
encoded with the chunked transfer-coding.
"Roy T. Fielding" <fielding at kiwi.ics.uci.edu> on 01/22/99 10:54:56 AM
To: Carl Kugler/Boulder/IBM
cc: http-wg at cuckoo.hpl.hp.com, ipp at pwg.org
Subject: Re: Resend: Re: IPP> Chunked POST: SUMMARY
-------------- next part --------------
>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.