httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "'Aaron Bannert'" <aa...@clove.org>
Subject Re: [PATCH] fix LimitRequestBody for all input handlers
Date Fri, 12 Apr 2002 19:29:52 GMT
On Thu, Apr 11, 2002 at 05:12:53PM -0700, Ryan Bloom wrote:
> > 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.
[...]
> > 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.


Ok, what's the word on this? Is my patch good or can we settle on another
way to do this and just be consistent?

-aaron

Mime
View raw message