Am 05.06.2015 um 01:37 schrieb Yann Ylavic ylavic@gmail.com:
On Fri, Jun 5, 2015 at 1:03 AM, Roy T. Fielding field...@gbiv.com wrote:
Hence, we might need a configurable way to ignore a client's ALPN, though I
doubt that
SSLalpn off is the right way to express that. Likewise,
On Fri, Jun 5, 2015 at 8:39 AM Stefan Eissing stefan.eiss...@greenbytes.de
wrote:
Am 05.06.2015 um 01:37 schrieb Yann Ylavic ylavic@gmail.com:
On Fri, Jun 5, 2015 at 1:03 AM, Roy T. Fielding field...@gbiv.com
wrote:
Hence, we might need a configurable way to ignore a client's
On Jun 4, 2015, at 9:19 AM, Stefan Eissing stefan.eiss...@greenbytes.de
wrote:
I think we need to clarify some things:
1. ALPN is initiated by the client. When a client does not send ALPN as part
of client helo, the SSL alpn callbacks are not invoked and the server does
not send any
On Fri, Jun 5, 2015 at 1:03 AM, Roy T. Fielding field...@gbiv.com wrote:
Hence, we might need a configurable way to ignore a client's ALPN, though I
doubt that
SSLalpn off is the right way to express that. Likewise, neither is
SSLAlpnPreference.
The server protocol(s) preference should be
On Thu, Jun 4, 2015 at 6:19 PM, Stefan Eissing
stefan.eiss...@greenbytes.de wrote:
I think we need to clarify some things:
1. ALPN is initiated by the client. When a client does not send ALPN as part
of client helo, the SSL alpn callbacks are not invoked and the server does
not send any
I think we need to clarify some things:
1. ALPN is initiated by the client. When a client does not send ALPN as part of
client helo, the SSL alpn callbacks are not invoked and the server does not
send any ALPN information back. This is different from NPN.
2. SSLAlpnPreference is intended as
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
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
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
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.
I do like that from a backport perspective though.
On Thu, Jun 4, 2015 at 8:08 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
On Thu, Jun 4, 2015 at 2:30 PM, Eric Covener cove...@gmail.com wrote:
On Thu, Jun 4, 2015 at 8:08 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
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
On Thu, Jun 4, 2015 at 2:39 PM, Yann Ylavic ylavic@gmail.com wrote:
On Thu, Jun 4, 2015 at 2:30 PM, Eric Covener cove...@gmail.com wrote:
On Thu, Jun 4, 2015 at 8:08 AM Yann Ylavic ylavic@gmail.com wrote:
I think what makes the thing a bit awkward is that the
negotiable/preferred
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
I tested the lined patch on a 2.4.x checkout with mod_h2 on OS X 10.10 and
openssl 1.0.2. All my tests ran fine.
//Stefan
Am 02.06.2015 um 16:56 schrieb Eric Covener cove...@gmail.com:
Can you test the latest rev of the backport candidate?
On Wed, Jun 3, 2015 at 3:43 PM, Stefan Eissing
stefan.eiss...@greenbytes.de wrote:
If a client sends ALPN information in its hello, it certainly can expect an
answer from the server.
Since in absence of any other modules, the httpd will do „http/1.1“, I think
that is a reasonable response.
On 06/03/2015 03:43 PM, Stefan Eissing 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“.
If a client sends
On Wed, Jun 3, 2015 at 3:43 PM, 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
I wonder if registering the ssl_callback_alpn_select callback
inconditionally could break some clients.
Are those (ALPN ready) always negociate http/1.1?
Otherwise we could check for sc-server-ssl_alpn_pref-nelts 0 (or
a dedicated SSLAlpnEnable) beforing using
SSL_CTX_set_alpn_select_cb().
In
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“.
If a client sends ALPN information in its hello, it certainly can
I additionally tested today on Ubuntu 14.04 LTS. Works for me.
Am 03.06.2015 um 12:56 schrieb Stefan Eissing stefan.eiss...@greenbytes.de:
I tested the lined patch on a 2.4.x checkout with mod_h2 on OS X 10.10 and
openssl 1.0.2. All my tests ran fine.
//Stefan
Am 02.06.2015 um 16:56
On Wed, Jun 3, 2015 at 4:45 PM, Yann Ylavic ylavic@gmail.com wrote:
This means enabling ALPN only if SSLALPNPreference is used.
Something like below :
Index: modules/ssl/mod_ssl.c
===
--- modules/ssl/mod_ssl.c(revision
Hmm, I cannot test this today since I am travelling.
If Jim wants to tag 2.5.13 this week, then either the current v4 patch makes it
in, or we need to postpone this. A changed patch on which my module (and
possibly others) chokes on, will not serve anyone I assume.
As with the don't send NPN
With the current (master) code of mod_h2, you'd probably need
something like the attached patch to handle a possible failure in
modssl_register_alpn(), because SSLALPNPreference was not configured
(as per my proposed mod_ssl patch).
On Wed, Jun 3, 2015 at 5:16 PM, Stefan Eissing
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
Can you test the latest rev of the backport candidate?
http://people.apache.org/~ylavic/httpd-2.4.x-alpn-v4.patch
On Mon, Apr 27, 2015 at 11:06 AM Stefan Eissing
stefan.eiss...@greenbytes.de wrote:
Am 25.04.2015 um 11:47 schrieb Kaspar Brand httpd-dev.2...@velox.ch:
On 22.04.2015
Am 29.04.2015 um 13:05 schrieb Kaspar Brand:
I did some formatting cleanup in r1676709 and put a patch for 2.4.x
online under
https://people.apache.org/~kbrand/mod_ssl-2.4.x-alpn_2015-04-29.diff.
This should hopefully make it easier for people to test and review (it's
an amalgamation of ten
It sounds like it could be a vhost thing. SSL_CTX is most likely not global,
but maybe unique for a vhost? I am not certain myself, maybe someone else with
more knowledge of mod_ssl could pitch in?
//Stefan
Am 01.06.2015 um 13:04 schrieb Rainer Jung rainer.j...@kippdata.de:
Am 29.04.2015
The key issue I had with the lack of optional functions on the old NPN
backport is addressed, that's great. Looks promising!
NPN is now irrelevant with ALPN, I presume?
On Wed, Apr 29, 2015 at 6:05 AM, Kaspar Brand httpd-dev.2...@velox.ch
wrote:
On 27.04.2015 17:04, Stefan Eissing wrote:
Am
On 27.04.2015 17:04, Stefan Eissing wrote:
Am 25.04.2015 um 11:47 schrieb Kaspar Brand httpd-dev.2...@velox.ch:
Only tested in terms of compiles both w/ and w/o HAVE_TLS_ALPN, so it
certainly needs more eyes before a backport proposal could be made.
There's also a TODO: we should have a
Thank You!!
Will review ASAP.
On Apr 29, 2015, at 7:05 AM, Kaspar Brand httpd-dev.2...@velox.ch wrote:
On 27.04.2015 17:04, Stefan Eissing wrote:
Am 25.04.2015 um 11:47 schrieb Kaspar Brand httpd-dev.2...@velox.ch:
Only tested in terms of compiles both w/ and w/o HAVE_TLS_ALPN, so it
Am 25.04.2015 um 11:47 schrieb Kaspar Brand httpd-dev.2...@velox.ch:
On 22.04.2015 18:54, Jim Jagielski wrote:
For me the time seems right to rip NPN out of trunk and only backport
the ALPN code to 2.4.
I'd be +1 for that.
So, to get one step further, and since there were no
On 22.04.2015 18:54, Jim Jagielski wrote:
For me the time seems right to rip NPN out of trunk and only backport
the ALPN code to 2.4.
I'd be +1 for that.
So, to get one step further, and since there were no explicit objections
to removing NPN support so far (or arguments for keeping it,
I don't know if I have any points to give here, but if NPN does not make it to
2.4, it's fine with me to remove it from trunk also. Only mod_spdy is affected
afaik.
//Stefan
Am 23.04.2015 um 06:56 schrieb Kaspar Brand httpd-dev.2...@velox.ch:
On 22.04.2015 21:30, Rainer Jung wrote:
Am
Am 23.04.2015 um 06:56 schrieb Kaspar Brand:
On 22.04.2015 21:30, Rainer Jung wrote:
Am 22.04.2015 um 17:49 schrieb Kaspar Brand:
Thanks. In the patch for ssl_private.h, the complete NPN block should
actually be dropped - the same block is are already part of
ssl_private.h, just 10 lines
Am 22.04.2015 um 17:49 schrieb Kaspar Brand httpd-dev.2...@velox.ch:
On 22.04.2015 10:52, Stefan Eissing wrote:
I made two small patches based on the feedback from Kaspar. One for
the code and one for the documentation.
Thanks. In the patch for ssl_private.h, the complete NPN block
For me the time seems right to rip NPN out of trunk and only backport
the ALPN code to 2.4.
I'd be +1 for that.
On 22.04.2015 10:52, Stefan Eissing wrote:
I made two small patches based on the feedback from Kaspar. One for
the code and one for the documentation.
Thanks. In the patch for ssl_private.h, the complete NPN block should
actually be dropped - the same block is are already part of
ssl_private.h,
Am 22.04.2015 um 17:49 schrieb Kaspar Brand:
On 22.04.2015 10:52, Stefan Eissing wrote:
I made two small patches based on the feedback from Kaspar. One for
the code and one for the documentation.
Thanks. In the patch for ssl_private.h, the complete NPN block should
actually be dropped - the
On 22.04.2015 18:45, Stefan Eissing wrote:
I understand your argument. My pov is of someone trying to bring
http/2 to the people. While bringing a new httpd on an existing
system seems easy, installing a new system openssl is more
challenging with its dependencies and the changes in hiding non
On 22.04.2015 21:30, Rainer Jung wrote:
Am 22.04.2015 um 17:49 schrieb Kaspar Brand:
Thanks. In the patch for ssl_private.h, the complete NPN block should
actually be dropped - the same block is are already part of
ssl_private.h, just 10 lines above.
I've kept the new one and dropped the
42 matches
Mail list logo
