From dev-return-43042-apmail-httpd-dev-archive=httpd.apache.org@httpd.apache.org Tue Jul 13 09:53:02 2004 Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 5963 invoked from network); 13 Jul 2004 09:53:02 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 13 Jul 2004 09:53:02 -0000 Received: (qmail 70774 invoked by uid 500); 13 Jul 2004 09:52:57 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 70602 invoked by uid 500); 13 Jul 2004 09:52: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 70587 invoked by uid 99); 13 Jul 2004 09:52:55 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [66.187.233.31] (HELO mx1.redhat.com) (66.187.233.31) by apache.org (qpsmtpd/0.27.1) with ESMTP; Tue, 13 Jul 2004 02:52:55 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6D9qse1014203 for ; Tue, 13 Jul 2004 05:52:54 -0400 Received: from radish.cambridge.redhat.com (radish.cambridge.redhat.com [172.16.18.90]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6D9qr005225 for ; Tue, 13 Jul 2004 05:52:53 -0400 Received: from radish.cambridge.redhat.com (localhost.localdomain [127.0.0.1]) by radish.cambridge.redhat.com (8.12.10/8.12.7) with ESMTP id i6D9qq7m031614 for ; Tue, 13 Jul 2004 10:52:52 +0100 Received: (from jorton@localhost) by radish.cambridge.redhat.com (8.12.10/8.12.10/Submit) id i6D9qpph031613 for dev@httpd.apache.org; Tue, 13 Jul 2004 10:52:51 +0100 Date: Tue, 13 Jul 2004 10:52:51 +0100 From: Joe Orton To: dev@httpd.apache.org Subject: Re: The Byterange filter -- a new design -- feel free to rip it to shreds Message-ID: <20040713095251.GD30998@redhat.com> Mail-Followup-To: dev@httpd.apache.org References: <40F1F1C6.4030400@apache.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N On Mon, Jul 12, 2004 at 03:35:12AM +0100, Nick Kew wrote: > This doesn't completely address the issue that this might cause > excessive memory usage; particularly if we have to serve ranges in a > perverse order. I would propose two admin-configurable limits: > > (1) Total data buffered in memory by the byterange filter. This can be > computed in advance from the request headers. If this is exceeded, the > filter should create a file bucket to store the data, and the ordered > list then references offsets into the file. Buffering responses into temporary files so that the byterange filter can do its job sounds extremely messy. I'm beginning to think the only sane way to fix the byterange filter is to have it do nothing if it isn't passed a complete EOS-terminated brigade with a predetermined length, i.e. no morphing CGI buckets which will eat all your RAM when they get ->read(). Being able to send byteranges of arbitrary dynamically generated content doesn't seem like an essential feature; the filter is just saying "I can't efficiently process a byterange request for this content". Clients must handle the 200 response fallback already. joe