On 02/04/2015 22:13, Christopher Schultz wrote: > Mark, > > On 4/2/15 4:33 PM, Mark Thomas wrote: >> I've been spending some time thinking about how to plumb in HTTP/2 >> support into the Tomcat 9 code base. After a couple of failed starts I >> think I have a good starting point that will be able to support NPN, >> ALPN and HTTP upgrade without making too much mess of the existing code. >> >> Before I commit it, I'd like to test it and that brings me to a small >> problem. The methods to set/get NPN protocols for OpenSSL are only >> available in tc-native trunk. >> >> OpenSSL has support for NPN in 1.0.1 and ALPN in 1.0.2. NPN is >> essentially deprecated in favour of ALPN but it looks like NPN will be >> around for a while. >> >> Given that OpenSSL support for 0.9.8 and 1.0.0 will cease at the end of >> this year, I'd like to propose the following: >> >> 1. Switch the focus of tc-native development to trunk. > > +1 > > Note that tcnative trunk often gets ignored when making fixes to the > 1.0.x branch (opposite of what tends to happen in the Java-based projects).
Indeed. I've been guilty of that. A review of the change history for the two is probably called for. >> 2a. tc-native trunk will require OpenSSL 1.0.1. >> or >> 2b. tc-native trunk will require OpenSSL 1.0.2. > > I'd prefer only requiring 1.0.1 if possible. Ack. >> 3. tc-native 1.1.x will move to a bug-fix only mode. > > It's pretty much there already. Not much new development is going on in > tcnative. > >> 4. Tomcat 9.0.x will require a minimum of at least 1.2.0. > > (And trunk will essentially be 1.2.x?) Yes. > +1 > >> Discussion of possible variations: >> 2a/b. Requiring a minimum of 1.0.2 would enable us to use ALPN rather >> than the deprecated NPN. I'm +0.5 for this. >> >> Thoughts? Assuming folks are broadly in favour, I'd like to get a build >> of tc-native 1.2.0-dev for Windows up at >> http://people.apache.org/~markt/dev/ for folks to play with next week. > > Can we reasonably auto-detect the OpenSSL version and adjust support > accordingly? Yes. > Or are you attempting to avoid even implementing NPN *at > all* because it's already deprecated? At this point, that is my preference. Various implementers have stated an intention to drop NPN but it remains to be seen how quickly that happens. > If you want to go directly to ALPN and skip NPN, will users still be > able to use HTTP/1.1 with tcnative and OpenSSL 1.0.1 or earlier? Yes, but we'd need to do something along the lines of the version detection you mentioned above to avoid some nasty error messages. > If so, then I think it's an okay requirement to say "you need 1.0.2 if > you want these new features". But if we are going to switch tcnative to > 1.0.2 for everything, I think that's a bit too much of a jump. There are > a LOT of people who are unable to upgrade various things due to all > kinds of foolish security requirements (though those are the people > still running 4.1.30, right?), and it would be nice to allow them to at > least be able to upgrade Tomcat if possible. 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. 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. 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 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. 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. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
