Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: domain of minfrin@sharp.fm designates
 72.32.122.47 as permitted sender)
Message-ID: <4AF86699.2070205@sharp.fm>
Date: Mon, 09 Nov 2009 20:59:37 +0200
From: Graham Leggett <minfrin@sharp.fm>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: Httpd 3.0 or something else
References: <C71DCC37.C85E2%Brian.Akins@turner.com>
In-Reply-To: <C71DCC37.C85E2%Brian.Akins@turner.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Akins, Brian wrote:

>>> It works really well for proxy.
>> Aka "static data" :)
> 
> Nah, we proxy to fastcgi php stuff, http java stuff, some horrid HTTP perl
> stuff, etc (Full disclosure, I wrote the horrid perl stuff.)

Doesn't matter, once httpd proxy gets hold of it, it's just shifting
static bits.

Something I want to teach httpd to do is buffer up data for output, and
then forget about the output to focus on releasing the backend resources
ASAP, ready for the next request when it (eventually) comes. The fact
that network writes block makes this painful to achieve.

Proxy had an optimisation that released proxied backend resources when
it detected EOS from the backend but before attempting to pass it to the
frontend, but someone refactored that away at some point. It would be
good if such an optimisation was available server wide.

I want to be able to write something to the filter stack, and get an
EWOULDBLOCK (or similar) back if it isn't ready. I could then make
intelligent decisions based on this. For example, if I were a cache, I
would carry on reading from the backend and writing the data to the
cache, while the frontend was saying "not now, slow browser ahead". I
could have long since finished caching and closed the backend connection
and freed the resources, before the frontend returned "cool, ready for
you now", at which point I answer "no worries, have the cached content I
prepared earlier".

Regards,
Graham
--