On Thu, Jul 6, 2017 at 12:28 PM, Jacob Champion <[email protected]> wrote: > > Administrators using prefork who would like to switch to HTTP/2 in the > future need to understand the limitations of the prefork architecture they > have selected. And sure, our users can request that we implement a solution > that "just works" with prefork, with the parent dispatcher that Stefan has > mentioned, and we can weigh the cost/benefit of implementing it. But IMO > it's not that onerous to ask our users to upgrade to a modern MPM if they > want a nice new protocol.
Agreed. Handling connections and requests on a 1:1 basis gains little from h2 protocol, other than a different path to TLS handshaking. As the h2 protocol corrupted the OSI model and wire format in the first place, clients are forced to deterministically wiggle their way into an h2 connection without telegraphing that dance to the end-user. So this should be completely opaque to the client's user, and similarly opaque to the server admin. The parent (root) process can never serve as the actual traffic dispatcher, much too risky. So the parent or a dedicated spawned process (preferable) would have to triage all the requests for child workers to an h2 connection by dispatching unix domain sockets between the connection's worker and the individual request workers, and then let them exchange data through the socket, because shared memory between connection and request workers would not behave the same way. In short, it would be an entirely new level of complexity, which the current project maintainers have no interest in engaging in. This worked with the mod_ftp only because the control channel (similar to the connection thread) has absolutely nothing to do during the singular data channel exchange, other than be watched for an ABOR; no other command is valid. h2 needs to lookaside for control directives from the connection channel while it is servicing each of the request workers. Prefork exists only because http/1 is a synchronous protocol, in that the server reads the user-agent's instructions and is left to act on that method and resource, with no other client interaction other than 101 continue or 102 upgrade (101 was especially disruptive but still largely ping-pong.) If the original protocol were http/2, prefork would never have been introduced. It's 2017. I've been threading my logic now over 30 years. Maybe it's time that Unix library developers and php community wake up to a new century? But as long as the fastcgi model persists, there is really no need to worry about any of this; run a threaded server and an fcgi pool of php app servers.
