Yeah... it was 'always' foreseen that mod_h2/mod_http2 would provide useful clues on how to make 2.6/3.0 better, especially w/ the idea of slave connections; basically, as you say, let the MPM make mod_http2's job easier by abstracting out a lot of the tricks that mod_http2 needs to do to something that the MPMs themselves provide.
At that same time, however, was/is the need/desire to support http/2 in 2.4.x (in fact, mod_h2 was *designed* w/ 2.4 in mind). So we are in this initial stage where what's in trunk isn't perfect for trunk (http/2-wise) but that's because it's really architectured for 2.4. Once 2.4.17 is out, then I expect mod_http2 to start diverging between the trunk and 2.4 variants, as the version in trunk drives the MPM designs there, which correspondingly drives mod_http2 in trunk as well (ala a feedback loop). My goal was/is to make motorz "ideally" suited to support http2. > On Oct 8, 2015, at 6:56 AM, Graham Leggett <minf...@sharp.fm> wrote: > > On 07 Oct 2015, at 4:30 PM, Stefan Eissing <stefan.eiss...@greenbytes.de> > wrote: > >> In http2 land, the request happen on "pseudo" connections, connections >> properly created by ap_run_create_connection(), but with own filters of type >> AP_FTYPE_PROTOCOL and AP_FTYPE_NETWORK, registered by mod_h2. >> >> These filters copy the data (or move the files) across the processing >> filters thread into the h2 multiplexer (h2_mplx) where the master connection >> thread reads it and send it out to the client, properly framed for HTTP/2. > > Having gone through this in a bit more detail (and slept on it) I > simultaneously see how we needed to do this to reach this point given the > limitations of the server, but at the same time this approach causes a number > of problems that we need to solve in the medium term (which is doable from > what I can see). > > What mod_http2 is doing is creating it’s own “mini-worker-mpm” inside the > module, and this creates a number of problems. The first is that code out > there that cares about being single threaded (historically php, for example) > suddenly finds itself running in a “pseudo-worker” MPM when the actual MPM in > use is prefork. This will cause unexpected breakage for people trying to use > http2. > > The second problem is that with mod_http2 being a “pseudo-mpm”, it needs to > emulate all the functions of an mpm in order to correctly do so. I believe > the problems with async filters are a manifestation of mod_http2 not > implementing all the capabilities of an MPM. We could try and make mod_http2 > do so, but I think ultimately we’re making life hard for ourselves - we > should really be leveraging the MPMs directly to make workers for us instead > of trying to bake workers of our own. > > So, bringing this down to actual practical stuff we can do to make this > happen, the basic problems to solve are: > > - The master connection currently runs under an existing MPM, and this works > fine today. > - The slave connection needs to run under an existing MPM instead of the > “pseudo MPM” it works under today. > - In theory, we can let the master connection and slave connection talk to > each other over two pairs of sockets otherwise created with socketpair() > (workaround for Windows at > http://code.activestate.com/recipes/525487-extending-socketsocketpair-to-work-on-windows/). > - We would need a mechanism to inject the just-created socket into the MPM’s > worker queue (ie in event MPM, call push2worker()), that would be an > additional call to MPMs that could support it. > - When the slave connection is accepted by the worker, the normal request > acceptance mechanism applies. We might signal the connection is an HTTP2 > slave connection on the request line in some way, or perhaps emulate HTTP/1.1 > (not sure if workable), will need to come up with a solution. > > Regards, > Graham > — >
