Re: http/2, spdy and bears, oh my!
hi, On Wed, Feb 5, 2014 at 8:09 PM, Jim Jagielski j...@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!
On Feb 6, 2014, at 4:07 AM, Graham Leggett minf...@sharp.fm wrote: On 05 Feb 2014, at 9:09 PM, Jim Jagielski j...@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!
On 05 Feb 2014, at 9:09 PM, Jim Jagielski j...@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 --
http/2, spdy and bears, oh my!
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...
