Netty 4.0.53.Final and 4.1.17.Final released
I'm happy to announce the latest bug-fix releases for our 4.0.x and 4.1.x series after another 5 weeks of development. These releases contains bug-fixes, performance enhancements and feature so we encourage everyone to upgrade.
The most important changes for 4.0.53.Final and 4.1.17.Final are:
- OpenSslEngine support unwrap plaintext greater than 214 and avoid infinite loop (#7352)
- java.lang.NullPointerException: ssl at ReferenceCountedOpenSslEngine.rejectRemoteInitiatedRenegotiation (#7353)
- Don't disable HttpObjectDecoder on upgrade from HTTP/1.x to HTTP/1.x over TLS (#7298)
- Support running Netty (in particular netty-tcnative) in the bootstrap class loader (#7345)
- SslHandler.setHandshakeTimeout*(...) should also been enforced on the server (#7277)
- ResourceLeakDetector sampling changes (#7232)
- Do not treat errors as decoder exception (redux) (#7279)
- Do not treat errors as decoder exception (#7276)
- Propagate all exceptions when loading native code (#7250)
- Optimistically update ref counts (#7248)
- Fix Java9SslEngine implementation of ApplicationProtocolAccessor and so fix ApplicationProtocolNegationHandler (#7258)
- Upgrade Conscrypt to 1.0.0.RC11 (#7235)
The most important changes for 4.1.17.Final only are:
- Add TCP_FASTOPEN_CONNECT epoll option (#7348)
- HTTP/2 Child Channel reading and flushing (#7344)
- Http2StreamFrameToHttpObjectCodec should handle 100-Continue properly (#7334)
- Fix possible leak in SslHandler if wrap(...) throws. (#7338)
- Trigger user event when H2 conn preface & SETTINGS frame is sent (#7330)
- Correctly update Channel writability when queueing data in SslHandler. (#7278)
- DnsResolver CNAME redirect bug (#7291)
- SslHandler promise completion incorrect if write doesn't immediately (#7380)
All changes that are in 4.0.53.Final are also included in 4.1.17.Final. All changes only have milestone 4.1.17.Final do not affect 4.0.53.Final.
As always, please let us know if you find any issues. We love feedback!
SslHandler behavior change on the server
Prior this release we did not take the handshake timeout into account (which is 10 seconds by default) on the server-side which could have the affect that an ssl handshake would never timeout. With this release this is fixed which has the affect that the handshake is failed if its not completed within 10 seconds by default. If you need a higher timeout please adjust the configuration on the SslHandler instance itself.
Every idea and bug-report counts and so we thought it is worth mentioning those who helped in this area. Please report an unintended omission.