httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: Httpd 3.0 or something else
Date Mon, 09 Nov 2009 19:06:35 GMT
On Mon, Nov 9, 2009 at 13:59, Graham Leggett <> wrote:
> 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".

These issues are already solved by moving to a Serf core. It is fully

Backend handlers will no longer "push" bits towards the network. The
core will "pull" them from a bucket. *Which* bucket is defined by a
{URL,Headers}->Bucket mapping system.


View raw message