W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1999

Re: IPP> Chunked POST

From: Carl Kugler <kugler@us.ibm.com>
Date: Tue, 17 Aug 1999 16:54:05 -0600
Message-ID: <37B9E80D.9EB58379@us.ibm.com>
To: http-wg@hplb.hpl.hp.com
> Re: IPP> Chunked POST
>
> Roy T. Fielding (fielding@kiwi.ics.uci.edu)
> Thu, 17 Dec 1998 22:03:24 -0800
>   ------------------------------------------------------------------------
>
> >In my opinion, Ken Coar is correct in saying that for a server to
> >be *both* HTTP/1.1 compliant and CGI/1.1 compliant it MUST buffer
> >chunked POST data and provide a Content-Length for the CGI script.
>
> Sending 411 is HTTP/1.1 compliant.  Failure to parse the chunked
> encoding (and puking) would be non-compliance, but requiring a
> content-length for a given resource is necessary for many reasons
> (DoS and legacy system protection).

This is a meaningless distinction.  Consider this thought experiment:  we have
two HTTP servers, A and B.

Server A can and does parse the chunked encoding.  But it sends a 411 "Length
Required" response with a "Connection: close" header in response to any
request that does not include a "Content-Length" header.  This is a compliant
server.

Server B understands no transfer-coding except "identity".  It cannot receive
or decode the "chunked" transfer-coding.  It sends a 411 "Length Required"
response with a "Connection: close" header in response to any request that
does not include a "Content-Length" header.   This is a non-compliant server.

If we look at these servers as black boxes, observing their behavior only
through their external interfaces, they are virtually indistinguishable
(unless we look at the product tokens or something).  So it's meanless to say
that all HTTP/1.1 applications that receive entities must understand (be able
to receive and decode) the “chunked” transfer-coding.


> ...

http://www.ics.uci.edu/pub/ietf/http/hypermail/1998q4/0210.html
Received on Tuesday, 17 August 1999 23:56:53 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:32 EDT