httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jus...@erenkrantz.com>
Subject RE: Peek at POSTed data
Date Tue, 17 Jun 2003 01:21:06 GMT
--On Monday, June 16, 2003 4:36 PM -0700 Michael Corcoran 
<mcorcoran@warpsolutions.com> wrote:

> 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.

The key problem is that once you've read the data from the network, you can't 
'unread' it.  Therefore, this means that the entire request body must be in 
memory.  And, that would make for a classical DoS attack (i.e. 100MB requests 
means 100MB in real memory).

So, yes, httpd could try to buffer back that unread data anyway (wrowe will 
call this 'pushback'), but any server that has this is going to be limited in 
the size of request bodies it can handle.

Hmm.  A thought.  Why are you trying to run in fixups?  Why not be an input 
filter and simply error the entire response when your condition is violated? 
Take a look at how http_protocol.c's ap_http_filter errors out when the 
request body size is exceeded.  The only caveat will be that *some* handlers 
may not read the input body - the core will read them afterwards.  But, if it 
never read the body, then why do you care what it was?  -- justin

Mime
View raw message