Subject: Re: IPP> Chunked POST

From: Carl Kugler <[email-masked]>
Date: Tue, 17 Aug 1999 16:54:05 -0600

> Re: IPP> Chunked POST
>
> Roy T. Fielding ([email-masked])
> 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

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 18 Aug 1999 05:08:18 -0700

>to receive and decode) the =93chunked=94 transfer-coding.

If the purpose of the text was to delineate one lame example from another,
then I'd agree with you.  The reason it is there is to prevent an HTTP/1.1
application from mistakenly thinking the chunked encoding is *no* encoding
and saving the chunk-sizes as part of the data.  As far as the protocol
is concerned, recognizing Transfer-Encoding chunked, and responding with
411 and connection close, is equivalent to parsing the chunked encoding.

Nobody is going to prevent you from building a server that responds with
411 to every request without implementing chunked.  It would be a dumb
thing to do, but the standard doesn't prevent people from doing dumb things
(only things that won't interoperate with others via HTTP).

....Roy

---

From: [email-masked]
Date: Thu, 19 Aug 1999 08:16:42 -0700

[email-masked] wrote: 
original article:http://www.egroups.com/group/http-wg/?start=8712
> (only things that won't interoperate with others via HTTP).

Isn't that what Apache does with chunked POSTs?

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 20 Aug 1999 10:47:01 -0700

>Isn't that what Apache does with chunked POSTs?

No.  It is what mod_cgi requires.  Apache implements chunked in the core,
where any module can make use of it if they so desire.

As I've said many times before, implementing a new protocol service
using CGI is a bad idea.  Making HTTP requirements based on the limitations
of CGI is even worse.

....Roy