tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: Time to switch tc-native development to trunk?
Date Fri, 03 Apr 2015 12:57:45 GMT
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:

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 

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


> 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).



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message