Netty 4.1.37.Final released
Today we announce the release of netty 4.1.37.Final. This release contains mostly bugfixes, but also deprecated some
HTTP/2 related classes and added replacements and adds some features. If you use
HTTP/2 please ensure to read the Important notes section
The most important changes in this release are:
- Don't filter out TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (#9274)
- Add null check to isSkippable. Fixes #9278 (#9280)
- Preserve the original filename when encoding a multipart/form in mixed mode (#9270)
- Fixed the haproxy message mem leak issue due unreleased TLVs (#9250)
- Allow to specify a EventLoopTaskQueueFactory for various EventLoopGroup implementations (#9247)
- codec-http2: Lazily translate cookies for HTTP/1 (#9251)
- Try to mark child channel writable again once the parent channel becomes writable (#9254)
- WebSocket is closed without an error on protocol violations (#9116)
- Writability state of http2 child channels should be decoupled from the flow-controller (#9235)
- Fix LZ4 encoder/decoder performance with (default) xxHash32 (#9249)
- Fix ReflectiveByteBufChecksum with direct buffers (#9244)
- SslHandler to fail handshake and pending writes if non-application write fails (#9240)
- Fix ByteBufChecksum optimisation for CRC32 and Adler32 (#9242)
- Handle missing methods on ChannelHandlerMask (#9221)
- HTTP/2 avoid closing connection when writing GOAWAY (#9227)
- Properly debounce wakeups (#9191)
- Close delegate resolver from RoundRobinInetAddressResolver (#9214)
- Don't read from timerfd and eventfd on each EventLoop tick (#9192)
- Add support for multicast when using native epoll transport (#9146)
- Correctly detect that KeyManagerFactory is not supported when using OpenSSL 1.1.0+ (#9170)
- Support handshake timeout in websocket handlers (#8856)
- Fix possible unsafe sharing of internal NIO buffer in CompositeByteBuf (#9169)
- KQueueEventLoop won't unregister active channels reusing a file descriptor (#9149)
- Prefer direct io buffers if direct buffers pooled (#9167)
- Add support for TCP fallback when we receive a truncated DnsResponse (#9139)
- ApplicationProtocolNegotiationHandler loses its place in the context too soon (#9131)
- DnsNameResolver.resolveAll(DnsQuestion) should not try to filter duplicates (#9141)
- Allow to have DnsNameResolver.resolveAll(...) notify as soon as the preferred records were resolved (#9136)
For the details and all changes, please browse our issue tracker for 4.1.37.Final.
Some of the changes done in the release deserve some more explantion. This section lists all of these.
If you used
Http2MultiplexCodec* in the past you will notice that
Http2MultiplexCodecBuilder are marked as
@deprecated in this release. The reason for this is that how it was implemented did result in a too tight coupling of
Http2MultplexCodec which made it impossible to add special handling of frames before these are multiplexed to the
As a replacement we now offer
Http2MultiplexHandler which only has the responsible of multiplexing and nothing more. This means that instead of having only
Http2MultiplexCodec in the
ChannelPipeline you will now need to add
Http2MultiplexHandler to the pipeline.
As an example this is how your "old" code may look as of today:
ChannelPipeline pipeline = ... pipeline.addLast(Http2MultiplexCodecBuilder.forServer(new HelloWorldHttp2Handler()).build()); ...
In the future it should be changed to:
ChannelPipeline pipeline = ... pipeline.addLast(Http2FrameCodecBuilder.forServer().build()); pipeline.addLast(new Http2MultiplexHandler(new HelloWorldHttp2Handler()); ...
While the semantics of the child channels (
Http2StreamChannel ) are mostly unchanged
Http2MultiplexHandler changes 2 things to make it easier for users to re-use code between
Http2ResetFrames are propagated to the
Http2StreamChannel as an user-event as these should not be affected on
AutoRead configurations of the child-channels and the user should be able to receive them ASAP (even if the user stopped reading for back-pressure reasons).
Http2WindowUpdateFrames are not propagated as these are not meaningful to the
Http2StreamChannel and just make writing generic code more difficult
Http2MultiplexCodec behave the same as before to not affect people that depend on the behavior.
DnsNameResolver TCP fallback
As defined by RFC7766(https://tools.ietf.org/html/rfc7766) resolvers should support TCP fallback in case the response is too large and so is truncated. This release add support for TCP fallback if you configure your
DnsNameResolverBuilder to do so before building the final
For example this code doesn't use TCP fallback (old behavior):
DnsNameResolver resolver = new DnsNameResolverBuilder(eventLoop) .channelType(NioDatagramChannel.class).build(); ...
To enable TCP fallback specify
DnsNameResolver resolver = new DnsNameResolverBuilder(eventLoop) .channelType(NioDatagramChannel.class) .socketChannelType(NioSocketChannel.class).build(); ...
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.