I think what makes the thing a bit awkward is that the negotiable/preferred ALNP identifiers (protocols) is configurable in both httpd (SSLAlpnPreference) and mod_h2 (hard coded). The former is only a hint while the latter is the real proposal to the client (with the fall back to "http/1.1").
Maybe it would be cleaner to let the modules register the ALPN identifiers (at configure time, with another optional function), and get rid of SSLAlpnPreference on mod_ssl side. If no identifier is registered, mod_ssl won't register the ALPN callback either, so that httpd continues to work without ALPN when not needed. WDYT? On Thu, Jun 4, 2015 at 12:45 PM, Bert Huijben <b...@qqmail.nl> wrote: > 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>: > > On Wed, Jun 3, 2015 at 8:43 AM, Stefan Eissing > <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. > > > >
