Yes, that's right - the toolkit does itself decide which protocol is used. However, it decides based on the order of the protocols we pass to it; that is, it will find the first protocol in the list supported by the client and negotiate it. We will order the list ourselves according to Protocols and ProtocolsHonorOrder.
The general structure of this toolkit's API is quite different OpenSSL's - it's not callback-based, all we do is pass it a bunch of parameters and then tell it to go ahead with the handshake. I think that may have influenced this API more than NPN. On Wed, Aug 26, 2015 at 11:20 AM, Stefan Eissing < stefan.eiss...@greenbytes.de> wrote: > Hmm, this was the kind of behaviour of NPN, maybe that influenced the API > of that toolkit? > > I imagine that the toolkit will decide itself then what protocol is > negotiated. That would mean that the directive ProtocolsHonorOrder has no > longer an effect. Am I right? > > I do not think that is what we want. > > //Stefan > > > Am 26.08.2015 um 17:02 schrieb Edward Lu <chaos...@gmail.com>: > > > > I was experimenting with the new support for declaring protocols for > e.g. ALPN, but with an SSL toolkit other than openssl. This one wants us to > pass the entire list of all the protocols the server supports in advance; > later, we can request the one protocol that the toolkit negotiated. > > > > It looks like the protocol_propose hook allows us to only grab a subset > of the protocols - i.e. it expects us to have the protocol list that the > client sends us. I've attached a patch which modifies the protocol_propose > hook's interface (documentation), allowing us to get all of the protocols > supported by the server. I also modified h2's implementation of the hook to > reflect the interface change. > > > > Let me know if anyone sees a problem. > > > > <all_protos.diff> > > <green/>bytes GmbH > Hafenweg 16, 48155 Münster, Germany > Phone: +49 251 2807760. Amtsgericht Münster: HRB5782 > > > >
