httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: PHP POST handling
Date Tue, 01 Oct 2002 22:26:38 GMT
On Tue, Oct 01, 2002 at 11:51:12AM -0700, Justin Erenkrantz wrote:
> --On Tuesday, October 1, 2002 11:12 AM -0700 Greg Stein <> 
> 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*.


Greg Stein,

View raw message