httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <>
Subject RE: [PATCH] fix LimitRequestBody for all input handlers
Date Fri, 12 Apr 2002 00:12:53 GMT
> From: Justin Erenkrantz []

> On Thu, Apr 11, 2002 at 04:34:08PM -0700, Aaron Bannert wrote:
> > I guess I'm unclear why it is CGI's responsibility to watch for
> > Do we then need to put these kinds of checks in every
> > element? (My relative newness to the filters is showing.)
> What happens in CGI if it gets APR_EGENERAL from ap_http_filter()?
> (I honestly don't know...)  This is what ap_http_filter() should be
> returning once the limit is reached.
> > Another thing I'm even less clear about is what ap_get_client_block
> > for. Where the heck do normal modules grab the entire post body from
> > (I truly don't know)?
> At this point, I don't believe anything.  They should just be
> using ap_get_brigade() - as ap_http_filter (HTTP_IN) does all of
> the dechunking seemlessly.  -- Justin

That's completely bogus.  There is a three step process to reading data
from the client.  The first is to do basic sanity checks on the input
data, ap_setup_client_block does this.  The second is to send a 100
Continue message to any 1.1 clients, ap_should_client_block does this.
The third and final is to actually read the data and put it into an
array, done by ap_get_client_block.

Finally, mod_cgi is never seeing the APR_EGENERAL.  Mod_cgi, like all
current modules, is using ap_get_client_block.  It is expecting all of
the error cases to be handled by the core itself.  As it should, because
those three functions make reading data MUCH easier for module authors.


View raw message