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 20:31:04 GMT
On Fri, Apr 12, 2002 at 01:18:19PM -0700, Justin Erenkrantz wrote:
> 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.  

I don't care if my change is wrong, this is a bug that needs to be
fixed and it seems to me that we can't agree what the correct solution
is. "Please figure out another way to do it" is not good enough.

> 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.

If we are allowing the non-ap_get_brigade() path then are we
requiring *all* modules that might deal with HTTP to have to
understand Content-length: and chunked encoding? If that is
the case, then we have far more than one bug to deal with.

> 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

That has nothing to do with my patch. Besides, I'm not even sure what
you are saying. When should and should not (in your opinion) -1 be
returned from ap_get_client_block?

-aaron

Mime
View raw message