Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 56935 invoked from network); 11 Nov 2003 20:39:31 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 11 Nov 2003 20:39:31 -0000 Received: (qmail 47480 invoked by uid 500); 11 Nov 2003 20:39:18 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 47144 invoked by uid 500); 11 Nov 2003 20:39:16 -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 47129 invoked from network); 11 Nov 2003 20:39:15 -0000 Received: from unknown (HELO scotch.ics.uci.edu) (128.195.24.168) by daedalus.apache.org with SMTP; 11 Nov 2003 20:39:15 -0000 Received: from [10.0.1.14] (pv106211.reshsg.uci.edu [128.195.106.211]) (authenticated bits=0) by scotch.ics.uci.edu (8.12.6/8.12.6) with ESMTP id hABKdGEG005865 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 11 Nov 2003 12:39:17 -0800 (PST) Date: Tue, 11 Nov 2003 12:39:16 -0800 From: Justin Erenkrantz To: dev@httpd.apache.org Subject: Re: should input filter return the exact amount of bytes asked for? Message-ID: <2147483647.1068554356@[10.0.1.14]> In-Reply-To: <5.2.0.9.2.20031111111704.02f07608@pop3.rowe-clan.net> References: <3FA7745A.3050507@stason.org> <3FA7745A.3050507@stason.org> <5.2.0.9.2.20031111111704.02f07608@pop3.rowe-clan.net> X-Mailer: Mulberry/3.1.0 (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 autolearn=no version=2.70-cvs X-Spam-Checker-Version: SpamAssassin 2.70-cvs (1.217-2003-10-04-exp) on scotch.ics.uci.edu X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N --On Tuesday, November 11, 2003 11:24 AM -0600 "William A. Rowe, Jr." wrote: >> More bytes = Not OK. (Theoretically possible though with bad filters.) > > Wrong. This is OK across the board, please consider; Uh, no. We changed the filter semantics some time ago to stop this insanity. It was inefficient to call AP_MODE_READBYTES and have it return more than asked for. Check out the CVS log for util_filter.h, specifically around revision 1.62. > module requests 1000 arbitrary bytes; > > codepage module requests 1000 > > http reads one 'chunk' available, 8000 bytes > and will return that page > > codepage can translate 7998 bytes and comes to > a screeching halt for a 3 byte sequence. returns > our Now Translated 4000 bytes > > module sees a 4000 byte heap bucket. > > What can you do? Instead of treating that bucket as a singleton > when you want 1000 bytes, consume the first 1000 bytes from that > bucket (or the brigade.) No. That means you have 3k more bytes you have to consume that you didn't ask for. The filter wouldn't return it again. Writing code that used input filters and having to deal with that it could get more than asked for was just confusing and led to lots of error-prone code. If it asks for 1k in AP_MODE_READBYTES, it gets at most 1k. Anything else is broken. (util_filter.h AP_MODE_READBYTES says as much, but that's not fair, because I wrote that comment.) > Please review the archives for this discussion (the brigades on the > apr list, the filter api on httpd.) This was a very long thread, but the > net result of filters is that you get what is available/handy, not any > specific number of bytes. That *was* indeed the position at one time, but when I redid the input filters (which was about rewrite #14 of input filters), we corrected this because it was causing lots of problems to return more than asked for - this is when we added the mode argument to ap_get_brigade. mod_ssl's input filtering code was just broken under that old API. And, the big boys even reviewed the code and semantic changes before it went in. So, it was definitely RTC. ;-) -- justin