W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 1999

Chunked POST (was Re: Unidentified subject!)

From: <kugler@us.ibm.com>
Date: Thu, 21 Jan 1999 10:13:04 -0700
To: http-wg@hplb.hpl.hp.com
Message-Id: <87256700.005E95E7.00@d53mta08h.boulder.ibm.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/307

 <pine.lnx.4.04.9901201238350.7238-10000-@hopf.math.nwu.edu> wrote:
Original Article: http://www.egroups.com/list/http-wg/?start=8494
> On Wed, 20 Jan 1999 kugler@us.ibm.com wrote:
> >
> >
> > Scott Lawrence  wrote:
> > Original Article: http://www.egroups.com/list/http-wg/?start=8491
> > > kugler@us.ibm.com wrote:
> > >
> > > > 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
> > > > without a defined Content-Length?  This would imply that a
> > > > HTTP/1.1 server MAY reject any request with the "chunked"
> > transfer-coding.
> > >
> > > First, I think that the note Harry Lewis sent titled "IPP> Chunking
> > > Explanation" [1] sums it up pretty well.  An HTTP server certainly
> > the
> > > option of using the "Length Required" code for whatever reason it
> > > to.
> > If this is the correct interpretation, then I was misled for a long
time by
> > the paragraph in section 4.4, "Message Length", that says "All HTTP/1.1
> > applications that receive entities MUST accept the 


> > transfer-coding (section 3.6), thus allowing this mechanism to be used
> > messages when the message length cannot be determined in advance. "  I
> > think it would be very helpful to have a note or warning added to that
> > paragraph;  perhaps:
> >
> > All HTTP/1.1 applications that receive entities MUST accept the
> > transfer-coding (section 3.6), thus allowing this mechanism to be used
> > messages when the message length cannot be determined in advance.
> > this does NOT mean that servers must accept HTTP/1.1 requests
containing a
> > message-body with the "chunked" transfer-coding.
> >
> > > My own judgement would be that a printer design that did not allow
> > > very large inputs of indeterminate length would be a poor one, and as
> > > result I would not choose an HTTP layer implementation that
restricted me
> > > to CGI.
> > >
> > Agreed.
> >
> I believe that the history of this problem has to do with the
> limitations of CGI/1.1 and the fact that it has been essentially
> frozen.  For a chunked message-body to go to a CGI program it must be
> unchunked.  CGI has not advanced with HTTP/1.1 so the CGI spec will
> only accept unchunked data of a known length.  This means that the
> only possibility is for the server to unchunk, buffer and calculate
> the length of the data.
> Some server implementations (most notably Apache) decided they were
> unwilling to do this -- presumably for efficiency reasons.  Hence
> while they are required to "accept" chunked message bodies they are
> not required to buffer them so they can be used by CGI.  This may make
> the notion of "accept" somewhat silly, but it is also silly to say
> data of arbitrary length must be accepted.

Could you clarify what the "accepted" notion of "accept" is?  To me, the
worst possible behavior is for a server to accept a chunked POST request,
respond with 200 (OK), but pass a zero-length entity-body to the service
(CGI or servlet).  This silent acceptance gives the client nothing to go
on.  At least if the server "rejects" the request with 411 (Length
a smart client could buffer the request itself and retry with

> This is unfortunate, because CGI, while not very efficient, is very
> flexible.  It provides a mechanism for existing installed servers to
> work with new applications.  It may be easy to rewrite a server to
> handle a new application or even create a new module and recompile,
> but those changes are not likely to affect the large installed base of
> servers.
> I can sympathize with the Apache developers view that unchunking and
> buffering message bodies on a site which gets millions of hits per day
> could be very problematic.  On the other hand applications, like
> printing will normally occur on a much smaller scale for which CGI is
> perfectly appropriate.  It is unfortunate that there seems to be no
> way out of this dilemma.
> Some servers do support unchunking and buffering for CGI, but the
> large majority do not.  There is no way to change this fact
> retroactively.  The bottom line is this is an implementation issue,
> not a protocol issue.  If implementors choose not to support
> functionality you need, you may just be stuck.
> John Franks
> john@math.nwu.edu

Carl Kugler
Received on Thursday, 21 January 1999 09:21:38 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:06 UTC