Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Date: Tue, 01 Oct 2002 11:51:12 -0700
From: Justin Erenkrantz <jerenkrantz@apache.org>
Reply-To: Justin Erenkrantz <jerenkrantz@apache.org>
To: dev@httpd.apache.org
Subject: Re: PHP POST handling
Message-ID: <2147483647.1033473072@[10.0.1.11]>
In-Reply-To: <20021001111246.H16732@lyra.org>
References: <20021001101658.D16732@lyra.org>
 <Pine.LNX.4.21.0210011320300.1671-100000@shell.ntrnet.net>
 <20021001111246.H16732@lyra.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--On Tuesday, October 1, 2002 11:12 AM -0700 Greg Stein <gstein@lyra.org> 
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.

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