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