On Tue, Oct 01, 2002 at 11:51:12AM -0700, Justin Erenkrantz wrote: > --On Tuesday, October 1, 2002 11:12 AM -0700 Greg Stein <[EMAIL PROTECTED]> > wrote: > > > I simply don't think that a filter should read/consume a request body. The > > handler is responsible for handling the request, which includes processing > > the body. > > Wellllll, PHP doesn't exactly do that. > > PHP's current strategy is to create an input filter that setsaside all > input. This is triggered by the ap_discard_request_body() call in > default_handler (as discard causes all data to be read). So, when data is > actually pushed down into the output filter chain, PHP has a copy of the > body in its private structure. And, if its script requires the body, it > returns the ctx->post_data value in its callbacks.
Ohmigod. I *really* didn't need to hear that. So you're saying that if I do "file upload" to a PHP script, and upload a 10 megabyte file, then it is going to spool that whole mother into memory? Oh oh... even better. Let's just say that the PHP script isn't even *thinking* about handling a request body. Maybe it is only set up for a GET request. Or maybe it *is* set up for POST, but only for FORM contents. But Mr Attacker comes along and throws 1 gigabyte into the request. What then? DoS? Swap hell on the server? > I think the biggest concern is when multiple modules want the input body. > Right now, it's fairly vague what will happen (and I'm not even sure what > the right answer is here). Forcing input filters and doing setasides (flat > void* instead of bb's in PHP) seems a bit clunky. However, we also don't > want to store the request body in memory. -- justin Agreed on all parts. I think a filter *can* read the request body (i.e. the content generator loads a PHP script, PHP runs it (as the first filter), reads the body, and loads content from a database). But that implies that the request body should not have been thrown out in the default handler. But it almost seems cleaner to say there is a series of stages which perform the request handling: process the body and generate the (initial) content. These stages could load a script from somewhere, run it, (repeat) and generate the content into the filter stack. Right now, we are confusing a *script* with *content*. Cheers, -g -- Greg Stein, http://www.lyra.org/
