> From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]]
> On Thu, Apr 11, 2002 at 04:34:08PM -0700, Aaron Bannert wrote: > > I guess I'm unclear why it is CGI's responsibility to watch for this. > > Do we then need to put these kinds of checks in every http-body-using > > element? (My relative newness to the filters is showing.) > > 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. > > > Another thing I'm even less clear about is what ap_get_client_block is > > for. Where the heck do normal modules grab the entire post body from > > (I truly don't know)? > > 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. Ryan
