[9] RFR 8170282: Enable ALPN parameters to be supplied during the TLS handshake

[Vincent Ryan]

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.lloyd at 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