httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <ylavic....@gmail.com>
Subject Re: ALPN patch comments
Date Thu, 04 Jun 2015 12:45:35 GMT
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 <jim@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.dev@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 <bert@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.eissing@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 <wrowe@rowe-clan.net>:
>>>
>>> On Wed, Jun 3, 2015 at 8:43 AM, Stefan Eissing
>>> <stefan.eissing@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.
>>>
>>>
>>>
>>>
>

Mime
View raw message