httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: about those async filters
Date Thu, 08 Oct 2015 11:45:17 GMT
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 <> wrote:
> On 07 Oct 2015, at 4:30 PM, Stefan Eissing <> 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
> - 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
> —

View raw message