httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <>
Subject Re: 2.4.27
Date Thu, 06 Jul 2017 17:49:22 GMT
On Thu, Jul 6, 2017 at 12:28 PM, Jacob Champion <> 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.

View raw message