httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <...@covalent.net>
Subject RE: [PATCH] fix LimitRequestBody for all input handlers
Date Fri, 12 Apr 2002 20:59:59 GMT
> From: Justin Erenkrantz [mailto:jerenkrantz@apache.org]
> Sent: Friday, April 12, 2002 1:18 PM
> To: Aaron Bannert; dev@httpd.apache.org
> Subject: Re: [PATCH] fix LimitRequestBody for all input handlers
> 
> On Fri, Apr 12, 2002 at 12:29:52PM -0700, 'Aaron Bannert' wrote:
> > 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?
> 
> Please figure out another way to do it.  Your change is wrong.
> 
> My take is that the non-ap_get_brigade() path (i.e.
> ap_get_client_block/mod_cgi) isn't handling the error case when
> ap_get_brigade says there is no data available due to the
> Limit case.
> 
> This lack of return codes to the application is why I believe
> that ap_get_client_block API is bogus.  I would expect -1 to be
> returned by ap_get_client_block (modules/http/http_protocol.c:1658).
> It also sets the keepalive to be -1 - which is bogus, IMHO.  -- Justin

I have explained three times now that there is no ap_get_brigade() path
that actually solves the problem.  Until you create a set of functions
that module authors can use to get data from the client, this is the
correct solution.  Think of ap_get_client_block as being analogous to
the handler functions.  Handlers generate content, get_client_block
consumes it.

Ryan



Mime
View raw message