Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 11832 invoked by uid 500); 3 Oct 2000 02:57:14 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 11821 invoked from network); 3 Oct 2000 02:57:13 -0000 Message-ID: <02e201c02ce3$8133d530$3bf1a218@apache> From: "Bill Stoddard" To: References: Subject: Re: cvs commit: apache-2.0/src/main http_core.c http_protocol.c Date: Mon, 2 Oct 2000 22:41:58 -0400 Organization: Apache Software Foundation MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N > > > Yes, I suspect it will need to be "done" by the core filter > > (or, to use a better term for it, the message envelope filter) > > since that is where chunks need to be coalesced as well. It > > was my impression that Bill's filter would be placed by the > > core filter and not by other filters, given that it is static > > to http_protocol.c. That is equivalent to buffering within > > the core filter. > > Being a static function doesn't mean it must be placed by the core > filter. As long as the function can be named at some point, it can be > added by anybody. This is why I want this as a part of the core > filter. Doing the buffering in multiple places, or anyplace other than > the core filter is a bit bogus. I disagree, but only until you can convince me otherwise. Buffering in the 'core' as in http_core is fine. Buffering needs to go in before the chunking filter, one way or the other, either in the buffer filter or in the routines that module writers use to do network i/o. The buffer_filter just seemed a logical first stab and maybe even the best solution. Bill