Roy and Carl,
I am now quite worried that there may be many cases of HTTP servers refusing
to accept chunked POST requests. Rejection is not just because of CGI
scripts. Apparently, denial of service is a reason that a conforming
HTTP/1.1 server might reject chunked encoding POST. Doesn't such rejection
jeopardize interoperability with IPP clients that send chunked POST
requests?
First, I'd like to understand more about such denial of service, since I
would think that a server would just timeout if the client didn't send the
next chunk in a reasonable amount of time. Also if the client sent too much
data with multiple chunks, the server could reject the next chunk with the
413 error code. So I don't understand the denial of service reason to allow
a conforming HTTP/1.1 server to reject a chunked request and am seeking
enlightenment.
Thanks,
Tom
>-----Original Message-----
>From: Roy T. Fielding [mailto:fielding at kiwi.ics.uci.edu]
>Sent: Friday, January 22, 1999 09:55
>To: kugler at us.ibm.com>Cc: http-wg at cuckoo.hpl.hp.com; ipp at pwg.org>Subject: Re: Resend: Re: IPP> Chunked POST: SUMMARY
>>>>The IPP WG would really like clarification on this point: Is
>the intent of
>>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.
>>....Roy
>