On Fri, Jul 10, 2015 at 10:35 AM, Stefan Eissing
<stefan.eiss...@greenbytes.de> wrote:
> Some weeks ago the backporting of the ALPN patch was rejected as
> a more generic approach was asked for.
>
> Some hinted that an approach of defining a list of supported
> "Protocols" per server/vhost and a general registry for some
> callbacks where mod_ssl and mod_h2 would work with.
>
> This and the 421 return code on mismatching host names are
> the technical obstacles of backporting mod_h2 to 2.4, it seems.
>
> Does someone feel like implementing such a thing? Shall I take
> a stab at it? How should it best be approached? A separate core
> module which stores things at its own server config? It needs
> to fit into 2.4 somehow...
my 2 cents, minimum to get it out of mod_ssl and support h2:
I don't think this should be in a separate module since the idea is
that this is the underlying list of app protocols the server will
speak -- just a new core (as in server/{core.c,protocol.c,request.c})
directive to set the protocol preference order in httpd.conf.
Extending the core_server_config is okay for backport
(apr_array_header_t of protocols supported and requested)
It would also need to track what protocols were supported by modules
at the VH level (I think this just means moving the mod_ssl optional
function for ALPN registration into the core)
It would need an API for a module like mod_ssl to tell the core the
protocols a client advertised, per-connection.
The core also probably needs to be the one that determines the one
negotiated protocol from the stuff above.
Finally, at least mod_ssl needs to know what was negotiated. A new
hook to tell anyone interested what was selected seems like overkill,
maybe mod_ssl just runs wherever it already does and calls some method
to get at the negotiated application protocol (based on conn_rec)
