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 que
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
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
Thanks! Added in 1670738.
> On Apr 1, 2015, at 12:22 PM, Stefan Eissing
> 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 SSLAlpnPreference
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 t
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 m