httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: http/2, spdy and bears, oh my!
Date Tue, 04 Mar 2014 15:08:15 GMT

On Feb 6, 2014, at 4:07 AM, Graham Leggett <> wrote:

> On 05 Feb 2014, at 9:09 PM, Jim Jagielski <> wrote:
>> With http/2 becoming closer and closer, and spdy being
>> in place as we speak, it seems that we should really
>> ramp up development on trunk to support these new techs.
>> Lets get serious on what needs to be done w/ trunk
>> to get there, and what our wish-list is for new capability
>> and architecture.
>> Taking a page from mod_spdy, breaking the connection->request
>> singularity looks like an interesting 1st step, maybe via
>> some sort of "virtual connection" which a real connection
>> can spin up/down and which corresponds to the request's
>> "actual" connection... 
> My moon-on-a-stick wishlist is as follows.
> I want more from the MPMs. Most specifically, what I want is:
> - The ability to create and associate additional connections with the original incoming
connection, creating a set of associated connections, all controlled by the same event loop.
> If mod_proxy wants to make a connection, I want to be able to tie it into the same event
loop that is driving the frontend. It should not matter where the connections come from, they
could be local pipes, doesn't matter.

Not only connections but also threads, that are treated as typical
MPM threads.

> - The ability to mask events.
> Messing around with lists of sockets is a colossal faff, ideally the MPM should worry
about this and the module developer shouldn't care. What I want is the ability, at any time,
to mask an event on a connection in a simple and easy to understand way.
> While I am waiting for a ready-to-read from a backend proxy, I want to mask the ready-to-write
to the frontend, and I don't want this to be fiddly.
> - First class support for openssl.
> The SSL protocol is a layer, meaning that while we may be trying to read, openssl underneath
might be trying to either read or write to perform a renegotiation. What openssl asks us to
do is switch to a write in the middle of a read, or a read in the middle of a write.
> We must support this properly from the get go with the ability to override the sense
of any event from a write to a read or a read to a write. In the past the MPMs have ignored
openssl expecting to handle it as some kind of special case, and this is wrong.
> Regards,
> Graham
> --

View raw message