Am 03.04.2015 um 11:33 schrieb Mark Thomas:
Keep in mind that the Java EE 8 schedule is that it won't be final until
at least the second half of 2016 so if we did require OpenSSL 1.0.2 that
would give it plenty of time to iron out any teething issues.
+1, that was my first thought. Although I expressed a -1 for basing the
windows build of 1.1.33 on 1.0.2, I think that 1.0.2 will definitely
become stable during the next few releases. So requiring it for 1.2.x
should be OK stability wise.
Availability wise I don't think, that tcnative 1.2 should be modelled
based on typical OS availability of dependencies today. For Windows we
provide binaries and for Linux/Unix building OpenSSL is not too hard. So
I would feel OK with demanding OpenSSL 1.0.2 even if most major Linux
distros still won't have it then.
The way tc-native trunk is structured at the moment, it is designed for
NPN to be optionally available (hence the SSLExt class). Having looked
at it some more, I think that part of the API could do with some clean-up.
Google plans to remove NPN support from Chrome (and SPDY) in early 2016:
http://blog.chromium.org/2015/02/hello-http2-goodbye-spdy-http-is_9.html
OTOH since h2 is build on ALPN all browsers should support ALPN already
or pretty soon because they are much behind h2. E.g. my Firefox 36
already has a config setting security.ssl.enable_alpn;true (and also
security.ssl.enable_npn;true).
So I'd suggest going directly for ALPN and ignoring NPN. But judging
from the code added to httpd trunk, adding NPN in addition to ALPN
wouldn't be hard either.
I'm still on the fence about the best way forward. The options I'm
mulling over are:
a) tcn 1.2.x requires OpenSSL 1.0.1 and only supports NPN
b) tcn 1.2.x requires OpenSSL 1.0.2 and only supports ALPN
I'd go for that one. And follow OpenSSL master/1.1 development and
releases to decide when 2016 is close, whether it has important
improvements and is stable.
c) tcn 1.2.x requires OpenSSL 1.0.2 and supports NPN & ALPN
d) tcn 1.2.x requires OpenSSL 1.0.1 and supports NPN. If built with
OpenSSL 1.0.2 it adds ALPN support and uses it in preference to NPN.
a) seems pointless given the rapid (for the web) move away from NPN.
b) nice and simple
+1
c) there have been some reports of issues using NPN and ALPN
side-by-side so given the time frame I'm not convinced the added
complexity is worth it.
d) I quite like this - especially if the NPN/ALPN choice is abstracted
away from the Java API and handled in tcn.
The migration from d) to b) is simple if we reach the stage where no
clients are using NPN.
Probably true. But worth it?
I think the most important factor is how quickly client implementations
drop NPN support. That is currently an unknown. I think option d) is the
one to follow for now but keep it under review over the next 12 months.
If lots of clients drop NPN support we'd either have to make HTTP/2
optional and only available if tcn is built with OpenSSL 1.0.2 or we'd
have to require tcn to be built with OpenSSL 1.0.2.
Maybe this would make early testing easier. But only tests of limited
scope(NPN plus maybe NPN plus SPDY, not h2).
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
