[9] RFR 8171443: (spec) An ALPN callback function may also ignore ALPN

[Vincent Ryan]

Hello Simone,

Throwing an exception is certainly another option but we chose these 3 specific return values for the callback
so that they match the existing behaviour of SSLEngine.getApplicationProtocol / SSLEngine.getHandshakeApplicationProtocol
and the SSLSocket equivalents.

http://download.java.net/java/jdk9/docs/api/javax/net/ssl/SSLEngine.html#getApplicationProtocol--
http://download.java.net/java/jdk9/docs/api/javax/net/ssl/SSLEngine.html#getHandshakeApplicationProtocol--
http://download.java.net/java/jdk9/docs/api/javax/net/ssl/SSLSocket.html#getApplicationProtocol--
http://download.java.net/java/jdk9/docs/api/javax/net/ssl/SSLSocket.html#getHandshakeApplicationProtocol--

BTW if a runtime exception does get thrown from the callback then it gets handled further up the call stack
where a TLS fatal alert will be returned.

I don’t think it is worth changing all these methods to throw an exception instead.
I’d prefer to keep the current behaviour.

Thanks.


> On 22 Dec 2016, at 11:06, Simone Bordet <simone.bordet at gmail.com> wrote:
> 
> Vincent,
> 
> On Thu, Dec 22, 2016 at 11:38 AM, Vincent Ryan
> <vincent.x.ryan at oracle.com> wrote:
>> Please review this spec change to allow an ALPN callback function to also disable ALPN usage
>> and return no ALPN extension value during a TLS handshake.
> 
> As I understand it, the callback needs to convey 3 results:
> 1. a success -> non empty string
> 2. a failure -> null
> 3. no action -> empty string
> 
> I wonder if it is better to convey the failure by throwing an exception ?
> This would also match the case where the implementation of the
> function, for any reason, throws an unexpected exception such as NPE
> or ClassCastException, etc.
> I expect the SSLEngine implementation to catch Throwable from the
> invocation of the callback and send back a TLS close message with code
> 120.
> 
> If the failure case is conveyed with an exception, then only 2 cases
> remain, and then null can be used to signal "no action" ?
> 
> The SSLEngine implementation should also check that the String
> returned is among those sent by the other peer, so an empty string is
> as invalid as the string "no_proto" - hence the choice of null to
> signal "no action".
> 
> Makes sense ?
> 
> Thanks !
> 
> -- 
> Simone Bordet
> http://bordet.blogspot.com
> ---
> Finally, no matter how good the architecture and design are,
> to deliver bug-free software with optimal performance and reliability,
> the implementation technique must be flawless.   Victoria Livschitz