httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <>
Subject Re: what to do about CGI and chunked
Date Mon, 25 Nov 1996 00:32:09 GMT
On Sat, 23 Nov 1996, Roy T. Fielding wrote:

> Here is my solution.  I've added a couple request_rec values for
> determining how the message body should be read and how much has
> been read.  This allows a module to select whatever level of
> sophistication they want, while ensuring that the data being read
> is complete and correct, and killing keepalive if it isn't (since
> otherwise the server would interpret the leftover garbage as a
> second request and send a second error response after the CGI response).
> Normal CGI scripts are not affected by the changes (other than the bug fixes).

Well, if I recall correctly, error messages kill keepalive anyhow,

> I tested all of the options by modifying the read_body value in
> mod_cgi.  Unfortunately, I can't test the changes to mod_fastcgi
> and mod_proxy (aside from compiling them). I'm not sure whether
> fastcgi should require Content-Length or not, so I set it so that
> it would dechunk and signal errors with -1.
> It is difficult to see how valuable this change is without a module or
> proxy that uses the more poweful chunking options.  All I can say is
> that we can't build an HTTP/1.1 gateway or proxy without them.
> It would also be nice if we had a configurable directive for limiting
> the size of a request message, since this gives the ability to enforce it.
> This is an API change, so we'll need to bump the version when this
> is committed.  That's also why it *really* needs to be reviewed now
> and not later.

Hmm. I haven't taken a very detailed look, but I have a few general

1) The calling module really shouldn't set anything in the request
directly. This is, IMHO, just a bad idea. The read_body thing should
be an argument to setup_client_block.

2) It's not neccessary to set anything to 0 in the request_rec
structure - it's done when its initialized.

3) "Assumes that caller will never pass a bufsiz <= 2". Nope, no can
do. An earlier version of get_client_block did assume this, and it
ran into a big problem with mod_fastcgi, which can actually send a
buffer size of 1. One-byte reads are perfectly acceptable. If the
module programmer wants to shoot themselves in the foot, at least
don't do it for them... (although we certainly can assume bufsiz is >=

I'll look over the code in more detail when I have more time.

Alexei Kosut <>      The Apache HTTP Server

View raw message