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
