We understood when we examined these issues last year that the existing ALPN API would be sufficient. However it transpired, following HTTP2 server implementation efforts, that a particular use-case was difficult to address without sacrificing performance.
This new API fixes that specific problem and the existing API is still available for the common case. > On 8 Dec 2016, at 23:13, David M. Lloyd <david.ll...@redhat.com> wrote: > > On 12/08/2016 04:18 PM, Vincent Ryan wrote: >> The Java Servlet Expect Group reported that they have identified a specific >> HTTP2 server use-case that cannot >> be easily addressed using the existing ALPN APIs. >> >> This changeset fixes that problem. It supports a new callback mechanism to >> allow TLS server applications >> to set an application protocol during the TLS handshake. Specifically it >> allows the cipher suite chosen by the >> TLS protocol implementation to be examined by the TLS server application >> before it sets the application protocol. >> Additional TLS parameters are also available for inspection in the callback >> function. >> >> This new mechanism is available only to TLS server applications. TLS clients >> will continue to use the existing ALPN APIs. > > Wasn't the entire point of the chosen ALPN solution to make this kind of > thing unnecessary? > > -- > - DML
