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 Thu, 11 Apr 2002 23:50:41 GMT

> From: Justin Erenkrantz []
> On Thu, Apr 11, 2002 at 01:02:37PM -0700, Aaron Bannert wrote:
> > Currently, if you set the LimitRequestBody and then do a POST
> > against a CGI resource with a body larger than the LimitRequestBody,
> > one of two broken things happen:
> >
> > 1) You get a closed socket and no returned data.
> > 2) you get the "normal" data from the cgi script, but no 413 error.
> >
> > It appears to be random which of these broken behaviors is returned.
> >
> > It seems to me that the proper way to handle this is not in the
> > http input filter, but instead in the ap_get_client_block function.
> No.  The limit needs to apply to *all* bucket reads not just the
> ap_get_client_block which we shouldn't even be supporting
> (it's old cruft from 1.3).  This patch is broken as inputs
> will not be limited if you don't use ap_get_client_block()
> (say use ap_get_brigade() - you won't limit it).
> I believe ap_http_input_filter is the right place.  You really
> need to make a case as to why this is wrong.  This really seems
> like CGI is broken.  -- Justin

Is there a single module out there getting input data without
ap_get_client_block?  There are a set of things that the core does with
ap_setup_client_block, ap_should_client_block, and ap_get_client_block.
Continuing to support those APIs allows us to solve the problems
described above, and allows module to easily implement 100 Continue

You really need to make a case as to why removing useful functions is
good thing.


View raw message