Return-Path: Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 17648 invoked by uid 500); 17 Jun 2003 01:20:55 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 17594 invoked from network); 17 Jun 2003 01:20:53 -0000 Date: Mon, 16 Jun 2003 18:21:06 -0700 From: Justin Erenkrantz To: dev@httpd.apache.org Subject: RE: Peek at POSTed data Message-ID: <2147483647.1055787666@dhcp31-80.ics.uci.edu> In-Reply-To: <6353D4DC26523B4587F5254CC0DD895101E19182@ehost006.intermedia.net> References: <6353D4DC26523B4587F5254CC0DD895101E19182@ehost006.intermedia.net> X-Mailer: Mulberry/3.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.60-cvs X-Spam-Checker-Version: SpamAssassin 2.60-cvs (1.186-2003-05-09-exp) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N --On Monday, June 16, 2003 4:36 PM -0700 Michael Corcoran 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