httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: Peek at POSTed data
Date Tue, 17 Jun 2003 01:19:01 GMT
Michael Corcoran wrote:
> I am not too familiar with the internals of Apache, so I apologize if this wish on my
wish list is way of base and I especially apologize if the following over simplifies what
would be required, but here it goes...
> Would it be possible to (or how would I?) be able to implement a function that would
have a prototype similar to ap_reset_post_body(request_rec, void *, int);  This function could
be called after someone has already run through the full ap_should_client_block/ap_get_client_block/etc.
procedure calls and drained the socket of any post body data.  The function would cause Apache
to think that none of the above functions had been called yet and use the buffer provided
as if it was the data sent by the user.

You have probably forgotten the discussion on httpd-apreq-2 filter. It's the 
library that provides a convenient C API (with glues in perl, php, tcl, etc) 
for manipulating request's data: POST, QUERY_STRING, Cookies, etc. Joe 
Schaefer has most of it working already. One of the functionalities that it's 
going to provide is injecting itself as an input filter and making the POST 
data available to any requestor in a reusable manner. For example modules 
written in C, Perl and PHP can all access the same POST data during the same 

> -----Original Message-----
> From: Justin Erenkrantz []
> Sent: Monday, June 16, 2003 3:35 PM
> To:
> Subject: Re: Peek at POSTed data
> --On Monday, June 16, 2003 4:17 PM -0500 "William A. Rowe, Jr." 
> <> wrote:
>>Why do you say that?  SSL is a connection level filter that can persist
>>beyond a single request.  There is nothing to say that one can't author a
>>pre-handler filter that looks at the post data before someone comes along
>>with some  get_client_block style call.
> And, where would you call this filter?  There is no real support for 
> non-destructive reads in our filtering system.  The only guarantee currently 
> is that the input filters will be invoked *after* the handler is invoked when 
> we discard the request body.  Handlers may very well not read the request body 
> and don't have to do so (although that sort of leads to the TCP deadlock we 
> discussed at last AC).  But, the essential issue is that with non-destructive 
> reads we open ourselves to a new class of DoS attacks.
> Also, request filters also can't be called before the handlers as the request 
> filters aren't necessarily in place until filter_init runs in 
> ap_invoke_handler().
> Trying to read the request body before the handlers has always been 
> problematic - even in 1.3.  -- justin


Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

View raw message