Re: svn commit: r1670397 - in /httpd/httpd/trunk/modules/ssl: mod_ssl.c mod_ssl.h ssl_engine_config.c ssl_engine_io.c ssl_private.h

2015-04-05 Thread Kaspar Brand
On 31.03.2015 19:12, j...@apache.org wrote: Author: jim Date: Tue Mar 31 17:12:51 2015 New Revision: 1670397 URL: http://svn.apache.org/r1670397 Log: ALPN support, based on mod_spdy/mod_h2 patch set Modified: httpd/httpd/trunk/modules/ssl/mod_ssl.c

Re: svn commit: r1670397 - in /httpd/httpd/trunk/modules/ssl: mod_ssl.c mod_ssl.h ssl_engine_config.c ssl_engine_io.c ssl_private.h

2015-04-02 Thread Stefan Eissing
Any reason to differ from trunk in 2.4? The people using spdy already in a 2.4 will most likely have the NPN patch deployed, so they'll have it easy with the trunk changes. The only one using the alpn patch, I know of, is myself in mod_h2. And that has already been adapted. So, I myself see

Re: svn commit: r1670397 - in /httpd/httpd/trunk/modules/ssl: mod_ssl.c mod_ssl.h ssl_engine_config.c ssl_engine_io.c ssl_private.h

2015-04-02 Thread Paul Querna
It seems reasonable to focus on ALPN support, and generally dropping NPN from trunk. NPN is already on a decline, and won't be used going forward. On Thu, Apr 2, 2015 at 12:44 AM, Stefan Eissing stefan.eiss...@greenbytes.de wrote: Any reason to differ from trunk in 2.4? The people using spdy

Re: svn commit: r1670397 - in /httpd/httpd/trunk/modules/ssl: mod_ssl.c mod_ssl.h ssl_engine_config.c ssl_engine_io.c ssl_private.h

2015-04-01 Thread Stefan Eissing
Jim, today I converted your commit to a path on 2.4.12 and tested it with mod_h2. All fine! Then I got a trouble report that alpn negotiation always selected http/1.1 unless SSLAlpnPreference configured something else. This is due to the deterministic ordering and http/1.1. h2. So, I made a

Re: svn commit: r1670397 - in /httpd/httpd/trunk/modules/ssl: mod_ssl.c mod_ssl.h ssl_engine_config.c ssl_engine_io.c ssl_private.h

2015-04-01 Thread Stefan Eissing
Well, I took the trunk version, diffed to 2.4.12 and made a patch for my sandbox build (removed the non alpn/npn parts). That works for mod_h2 after adding callbacks for the npn stuff. I have no real pref to keep npn and alpn separate or not. my thought when merging these was that npn will go

Re: svn commit: r1670397 - in /httpd/httpd/trunk/modules/ssl: mod_ssl.c mod_ssl.h ssl_engine_config.c ssl_engine_io.c ssl_private.h

2015-04-01 Thread Jim Jagielski
Thanks! Added in 1670738. On Apr 1, 2015, at 12:22 PM, Stefan Eissing stefan.eiss...@greenbytes.de wrote: Jim, today I converted your commit to a path on 2.4.12 and tested it with mod_h2. All fine! Then I got a trouble report that alpn negotiation always selected http/1.1 unless

Re: svn commit: r1670397 - in /httpd/httpd/trunk/modules/ssl: mod_ssl.c mod_ssl.h ssl_engine_config.c ssl_engine_io.c ssl_private.h

2015-04-01 Thread Jim Jagielski
Yeah, there is some overlap which I'm trying to grok, since trunk had NPN but not ALPN, so I tried to have the ALPN stuff self-contained. But not sure if that's the best way since, for example, alpn_proposefns is adjusted in ssl_callback_AdvertiseNextProtos(), but that is a NPN only function in

Re: svn commit: r1670397 - in /httpd/httpd/trunk/modules/ssl: mod_ssl.c mod_ssl.h ssl_engine_config.c ssl_engine_io.c ssl_private.h

2015-04-01 Thread Rainer Jung
Hi Stefan, Am 01.04.2015 um 18:22 schrieb Stefan Eissing: Jim, today I converted your commit to a path on 2.4.12 and tested it with mod_h2. All fine! Then I got a trouble report that alpn negotiation always selected http/1.1 unless SSLAlpnPreference configured something else. This is due to

Re: svn commit: r1670397 - in /httpd/httpd/trunk/modules/ssl: mod_ssl.c mod_ssl.h ssl_engine_config.c ssl_engine_io.c ssl_private.h

2015-04-01 Thread Jim Jagielski
Yeah, I agree. Right now, trunk pretty much uses #ifdef HAVE_TLS_ALPN blah blah #endif #ifdef HAVE_TLS_NPN blah2 blah2 #endif Instead of #if defined(HAVE_TLS_NPN) || defined(HAVE_TLS_ALPN) so that ripping out NPN would be easier. The

Re: svn commit: r1670397 - in /httpd/httpd/trunk/modules/ssl: mod_ssl.c mod_ssl.h ssl_engine_config.c ssl_engine_io.c ssl_private.h

2015-03-31 Thread Jim Jagielski
Hmmm.. missed a patch. r1670434 On Mar 31, 2015, at 2:28 PM, Jim Jagielski j...@jagunet.com wrote: Hmmm... let me double check. On Mar 31, 2015, at 2:22 PM, Ruediger Pluem rpl...@apache.org wrote: On 03/31/2015 08:08 PM, Jim Jagielski wrote: They are used by mod_spdy and/or

Re: svn commit: r1670397 - in /httpd/httpd/trunk/modules/ssl: mod_ssl.c mod_ssl.h ssl_engine_config.c ssl_engine_io.c ssl_private.h

2015-03-31 Thread Jim Jagielski
They are used by mod_spdy and/or mod_h2..., iirc On Mar 31, 2015, at 1:57 PM, Ruediger Pluem rpl...@apache.org wrote: On 03/31/2015 07:12 PM, j...@apache.org wrote: Author: jim Date: Tue Mar 31 17:12:51 2015 New Revision: 1670397 URL: http://svn.apache.org/r1670397 Log: ALPN

Re: svn commit: r1670397 - in /httpd/httpd/trunk/modules/ssl: mod_ssl.c mod_ssl.h ssl_engine_config.c ssl_engine_io.c ssl_private.h

2015-03-31 Thread Ruediger Pluem
On 03/31/2015 07:12 PM, j...@apache.org wrote: Author: jim Date: Tue Mar 31 17:12:51 2015 New Revision: 1670397 URL: http://svn.apache.org/r1670397 Log: ALPN support, based on mod_spdy/mod_h2 patch set Modified: httpd/httpd/trunk/modules/ssl/mod_ssl.c

Re: svn commit: r1670397 - in /httpd/httpd/trunk/modules/ssl: mod_ssl.c mod_ssl.h ssl_engine_config.c ssl_engine_io.c ssl_private.h

2015-03-31 Thread Ruediger Pluem
On 03/31/2015 08:08 PM, Jim Jagielski wrote: They are used by mod_spdy and/or mod_h2..., iirc They use private structures of mod_ssl directly? That does not sound like a good idea. Regards RĂ¼diger On Mar 31, 2015, at 1:57 PM, Ruediger Pluem rpl...@apache.org wrote: On 03/31/2015

Re: svn commit: r1670397 - in /httpd/httpd/trunk/modules/ssl: mod_ssl.c mod_ssl.h ssl_engine_config.c ssl_engine_io.c ssl_private.h

2015-03-31 Thread Jim Jagielski
Hmmm... let me double check. On Mar 31, 2015, at 2:22 PM, Ruediger Pluem rpl...@apache.org wrote: On 03/31/2015 08:08 PM, Jim Jagielski wrote: They are used by mod_spdy and/or mod_h2..., iirc They use private structures of mod_ssl directly? That does not sound like a good idea.