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

[Simone Bordet]

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