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.



-----Original Message-----
From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]
Sent: Monday, June 16, 2003 3:35 PM
To: [EMAIL PROTECTED]
Subject: Re: Peek at POSTed data


--On Monday, June 16, 2003 4:17 PM -0500 "William A. Rowe, Jr." 
<[EMAIL PROTECTED]> 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

Reply via email to