Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 76943 invoked by uid 500); 16 Feb 2001 17:56:01 -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 76929 invoked from network); 16 Feb 2001 17:55:58 -0000 Sender: rederpj@raleigh.ibm.com Message-ID: <3A8D6962.81204493@raleigh.ibm.com> Date: Fri, 16 Feb 2001 12:54:42 -0500 From: "Paul J. Reder" X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.14-15mdksecure i686) X-Accept-Language: en MIME-Version: 1.0 To: new-httpd@apache.org Subject: Re: cvs commit: apr-util/buckets apr_buckets_file.c (fwd) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N rbb@covalent.net wrote: > > The second problem is one I haven't fixed however. Brian, if you increase > the size of your file to 10Meg, then mod_include will read all 10Meg into > memory before sending it down the stack. That's BAD! mod_include needs > to be taught how to stream data when there are no SSI tags in the file. > > I will be adding the second issue to STATUS. Brian, please test the > latest code on OS/2. I can work on this. The question is how to decide when to send it on down? Should there be a #defined threshold value? System wide or mod_include specific? I would assume that as I am parsing through the bucket(s) I just keep track of the number of bytes parsed and break/pass the brigade when I cross the threshold, yes? This should be pretty easy. With a couple of answers I should have a fix pretty quickly. -- Paul J. Reder ----------------------------------------------------------- "The strength of the Constitution lies entirely in the determination of each citizen to defend it. Only if every single citizen feels duty bound to do his share in this defense are the constitutional rights secure." -- Albert Einstein