But certainly there are cases were mod_h2 is NOT part of the running system, in which case we still need some way to handle ALNP.
> On Jun 4, 2015, at 8:07 AM, Yann Ylavic <ylavic....@gmail.com> wrote: > > 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. >> >> >> >>
