Right, but we can still register our own IDs when httpd will handle them (with a new directive or by the new module itself).
On Thu, Jun 4, 2015 at 2:26 PM, Jim Jagielski <j...@jagunet.com> wrote: > 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. >>> >>> >>> >>> >
