From dev-return-39882-apmail-httpd-dev-archive=httpd.apache.org@httpd.apache.org Fri Nov 14 08:48:28 2003 Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 82196 invoked from network); 14 Nov 2003 08:48:28 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 14 Nov 2003 08:48:28 -0000 Received: (qmail 80696 invoked by uid 500); 14 Nov 2003 08:48:00 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 80431 invoked by uid 500); 14 Nov 2003 08:47:58 -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 80418 invoked from network); 14 Nov 2003 08:47:58 -0000 Received: from unknown (HELO scotch.ics.uci.edu) (128.195.24.168) by daedalus.apache.org with SMTP; 14 Nov 2003 08:47:58 -0000 Received: from [10.0.1.16] (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 hAE8m9EG021764 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 14 Nov 2003 00:48:10 -0800 (PST) Date: Fri, 14 Nov 2003 00:48:09 -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.1068770889@[10.0.1.17]> In-Reply-To: <3FB3D525.9050205@stason.org> References: <3FA7745A.3050507@stason.org> <20031111093124.GD20484@scotch.ics.uci.edu> <3FB342F6.9000900@stason.org> <2147483647.1068685304@[10.0.1.15]> <3FB3D525.9050205@stason.org> 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 Thursday, November 13, 2003 11:01 AM -0800 Stas Bekman wrote: > Should we add an explicit explanation to AP_MODE_READBYTES: return at most > readbytes data. Can't return 0 with APR_BLOCK_READ. Can't return more than > readbytes data. I'd say the first and last one are equivalent statements. And, that APR_BLOCK_READ description belongs with the definition of APR_BLOCK_READ not AP_MODE_READBYTES. > Also while we are at it I have a few more questions: > > /** The filter should return at most one line of CRLF data. > * (If a potential line is too long or no CRLF is found, the > * filter may return partial data). > */ > AP_MODE_GETLINE, > > does it mean that the filter should ignore the readbytes argument in this > mode? I think so, yes. > /** The filter should implicitly eat any CRLF pairs that it sees. */ > AP_MODE_EATCRLF, > > does it mean that it should do the same as AP_MODE_GETLINE but kill CRLF? If > not how much data is it supposed to read? Or is it a mode that never goes on > its own and should be OR'ed with some definitive mode, e.g.: > AP_MODE_GETLINE|AP_MODE_EATCRLF and AP_MODE_READBYTES|AP_MODE_EATCRLF? It's meant to be called right before we read the next pipelined request on the connection. Old (really old) Netscape clients added spurious CRLFs between requests. I don't see a clear rationale why it'd have to be 'combined' with other ap_get_brigade() modes. The only one that'd make sense (to me) is AP_MODE_GETLINE. Note that AP_MODE_EATCRLF doesn't necessarily return anything. It's wildly HTTP specific... > Though it'd be nice to add a note re: APR_BLOCK_READ in the > AP_MODE_READBYTES doc above. Or I guess may be it belongs to some filters > tutorial... I'll note that I wrote an article on describing httpd-2.x's filters for some Linux magazine recently. I bet you can find back issues. As an aside, I never actually saw the final copy or the printed copy. So, don't blame me if it doesn't help. ;-) -- justin