http/2, spdy and bears, oh my!

[Jim Jagielski <ji...@jaguNET.com>]

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... 

Re: http/2, spdy and bears, oh my!

[Pierre Joye <pi...@gmail.com>]

hi,

On Wed, Feb 5, 2014 at 8:09 PM, Jim Jagielski <ji...@jagunet.com> 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...

By the way, I was wondering what the Apache strategy here. Do you plan
to implement your own httpbis stack or use existing library like
https://github.com/tatsuhiro-t/nghttp2?

-- 
Pierre

@pierrejoye | http://www.libgd.org

Re: http/2, spdy and bears, oh my!

[Jim Jagielski <ji...@jaguNET.com>]

On Feb 6, 2014, at 4:07 AM, Graham Leggett <mi...@sharp.fm> wrote:

> On 05 Feb 2014, at 9:09 PM, Jim Jagielski <ji...@jaguNET.com> 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
> --
> 

Re: http/2, spdy and bears, oh my!

[Graham Leggett <mi...@sharp.fm>]

On 05 Feb 2014, at 9:09 PM, Jim Jagielski <ji...@jaguNET.com> 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.

- 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
--