> From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]] > > On Thu, Apr 11, 2002 at 01:02:37PM -0700, Aaron Bannert wrote: > > Currently, if you set the LimitRequestBody and then do a POST request > > 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 responses. You really need to make a case as to why removing useful functions is good thing. Ryan
