Re: Working towards HTTP3 - current MPM's only support TCP connections

Thanks for the detailed thoughts. I need to ponder them some more, this 
seems like a good direction for long-term.

My concern is that waiting for the full design could delay HTTP/3 work. 
The mod_http3 project is still young and has a lot of maturing ahead of it.

I propose retargeting PR #699 to the 2.4.x series as an enabling step, 
while developing the broader design on 2.5.x. This would let the 
community continue to grow, test, and gather feedback on mod_http3 in 
parallel.

mod_http3 would adopt an odd/even release strategy. 0.2.0 could target 
stable httpd 2.4.x, while 0.3.0-dev targets httpd 2.5.x-dev. When httpd 
2.6.x is released, we could then ship mod_http3 0.4.0 as the 
corresponding stable release, perhaps ready to be bundled with httpd by 
then.

On 2026-08-16 14:28, Graham Leggett via dev wrote:
> On 07 Aug 2026, at 15:05, Steffen <[email protected]> wrote:
>
>> Developing an HTTP3 module for Apache HTTPD is something that is 
>> desperately needed, noting alternative web servers already offer 
>> HTTP3 support, e.g. NGINX and Caddy.
>
> This is very cool work, happy to help you.
>
>> Whilst there's evidence of people actively working towards this, e.g. 
>> https://github.com/machine-moon/mod_http3, it's evidently not 
>> possible with the current 2.4.x code branch. To that end PR#699 
>> https://github.com/apache/httpd/pull/699 has been raised, as a 
>> workaround to allow (some) MPM's to note connections that are not TCP 
>> based.
>>
>> The following post provides a detailed insight to these issues - 
>> https://codeit.guru/apache-http3-pr-699-mpm-quic-backport-2-4-68
>
> Not had a chance to look at the code yet, but some comments on the 
> post above.
>
> Brain dump to follow.
>
> "The pull request proposes two optional MPM functions"
>
> Optional functions come with the limitation that only one module can 
> grab them. Ideally instead of optional functions they should be hooks, 
> this allows more than one module to be present and do potentially do 
> work in different ways.
>
> One place where httpd definitely needs a hook is receiving socket 
> descriptors.
>
> Right now there is code hardcoded in httpd core that is aware of 
> systemd for example, which can pass a pre-opened socket to httpd. That 
> really should be a hook that is called when some code in a module has 
> a socket ready. The core can be pure "open TCP or UDP", while an extra 
> module can be systemd.
>
> This means systemd can pass UDP sockets to mod_http3 in future and it 
> just works.
>
> "Every successful call to: ap_mpm_note_extra_connection_added() must 
> eventually have exactly one matching call to: 
> ap_mpm_note_extra_connection_removed()"
>
> This is largely impractical, it is pretty much guaranteed that an 
> error path will be mishandled at some point, which will lead to 
> instability in the server.
>
> The way httpd handles this is through the use of memory pools 
> (arenas), each unit of work in httpd has its own pool. When the unit 
> of work is finished, because it succeeded or failed, doesn't matter, 
> the memory is cleaned up as a single unit, along with any extra 
> resources like connection handles etc.
>
> https://apr.apache.org/docs/apr/1.7/group___pool_cleanup.html
>
> Pools are hierarchical, for example a request is created from a 
> connection. If the request ends for whatever reason, run 
> apr_pool_destroy(r->pool) will make that request go away. If the 
> connection dies for whatever reason, run apr_pool_destroy(c->pool) and 
> the connection, along with any requests currently in progress, will 
> all go away.
>
> Sometimes you might have a relationship between things that aren't 
> nested, like an LDAP connection pool. The LDAP connection pool lives 
> alongside HTTP requests. While the LDAP connection is being used by a 
> request, a cleanup is registered with the request to return the LDAP 
> connection to the pool at the end. No matter what happens to the 
> request, sanity returns to the LDAP connection pool.
>
> What all this means is that you need just one call, 
> ap_mpm_note_extra_connection_added(), which is passed a pool, and it's 
> the job of your code to register a cleanup in that pool.
>
> "The MPM owns the process lifecycle, but protocol modules may own 
> additional connection lifecycles and report them through a defined API."
>
> We have the option to rethink how nghttp3 and httpd mesh with one 
> another, and given certain limitations inside the core, this is likely 
> to be necessary.
>
> Thinking out loud, the first hook needed is the hook that allows us to 
> open TCP or UDP sockets, either natively or from systemd, at or around 
> make_sock() here 
> https://github.com/apache/httpd/blob/trunk/server/listen.c#L72
>
> Then each MPM would need a hook to pass UDP packets to. This hook 
> might use ngtcp2 or openssl to decode the packets, and then pass to a 
> hook that does nghttp3.
>
> nghttp3 would the make a conn_rec out of nghttp3_conn, and then make a 
> request_rec out of the callbacks for headers.
>
> The entry point where the request is processed is possibly here at 
> ‎ap_process_async_request‎():
>
> https://github.com/apache/httpd/blob/trunk/modules/http/http_request.c#L406
>
> Alternatively, if the above function has too many side effects, run 
> these three hooks ap_run_quick_handler‎(), 
> ap_process_request_internal‎(), and ap_invoke_handler‎() one after the 
> other and process the return code appropriately:
>
> https://github.com/apache/httpd/blob/trunk/modules/http/http_request.c#L447
> https://github.com/apache/httpd/blob/trunk/modules/http/http_request.c#L449
> https://github.com/apache/httpd/blob/trunk/modules/http/http_request.c#L451
>
> You would need to replace the connection filters with a filter that 
> injects data into the request, and then allows writing of data from 
> the request.
>
> The filter would return EAGAIN until all the request is read, and 
> unlike ap_process_async_request‎(), you would pass more data in and 
> keep going until that hook is happy.
>
> Some work might be required to make sure things are properly 
> re-entrant, but that's doable and reasonable I think.
>
> At the end of ap_invoke_handler‎() you will have buckets ready to be 
> written, you can write those buckets to the network and process the 
> next request. Make sure you limit the number of requests in flight 
> like this lest you run out of file handles.
>
>> We believe it would be really helpful if PR#699 could be approved for 
>> subsequent 2.4.x releases, and equally whether similar functionality 
>> could be added to mpm_winnt, so support for HTTP3 could be developed 
>> for Windows platforms too.
>
> Windows has its own http3 implementation called MsQuic, if the hooks 
> above are created carefully it should be possible to switch in MsQuic 
> instead of ngtcp2/nghttp3.
>
> Regards,
> Graham
> --
>
-- 
Cheers,
Tarek

GPG Fingerprint: B9BD295C26A1ED077599810CA284507F96DB79EF