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 —
