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.bor...@gmail.com> wrote: > > Vincent, > > On Thu, Dec 22, 2016 at 11:38 AM, Vincent Ryan > <vincent.x.r...@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
