Can we really do ALPN per vhost?
If this is handled before or at the same time as SNI, then SSLAlpnEnable is
eventually applied per listening address, while H2Engine would make sense even
for multiple hosts at the same ip.
I would say returning some error is a valid response for not enabling H2Engine
on a VHost, while still handling ALPN when explicitly disabled is not.
Bert
From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de]
Sent: woensdag 3 juni 2015 22:20
To: dev@httpd.apache.org
Subject: Re: ALPN patch comments
That is why mod_h2 allowe "H2Engine on|off" on base server and vhosts. If I
understand you correctly, this does what you ask for.
//Stefan
Am 03.06.2015 um 19:45 schrieb William A Rowe Jr <wr...@rowe-clan.net
<mailto:wr...@rowe-clan.net> >:
On Wed, Jun 3, 2015 at 8:43 AM, Stefan Eissing <stefan.eiss...@greenbytes.de
<mailto:stefan.eiss...@greenbytes.de> > wrote:
Hmm, personally, I do not like redundant configurations. If someone configures
a module, like mod_h2, to be enabled (H2Engine on), she could expect the module
to take all the necessary steps. So I am no fan of a „SSLAlpnEnable“.
The reason boils down to vhosts and interop. If someone does not wish
for a specific vhost (perhaps interacting with bad clients, or created for
backwards compatibility) to respond with a feature, it is useful to have
a fine-grained toggle. The default -could- be 'enabled', although this
probably should not happen on the stable/maintenance branches, but
simply on the future release branch, to avoid surprises.
OpenSSL does the wrong thing in some cases with respect to TLS/SNI
and my current patch development - in some respect - is backing out
that callback change for customers who have been burned by this
specific nonsense. You should reconsider absolutist behaviors,
because they make it much harder for people to inject 'experimental'
behaviors into specific hosts.
