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
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
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
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
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
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
