Skip navigation

Netty 4.1.37.Final released

by normanmaurer
on

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.

Important notes

Some of the changes done in the release deserve some more explantion. This section lists all of these.

Http2MultiplexCodec* deprecation

If you used Http2MultiplexCodec* in the past you will notice that Http2MultiplexCode and 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 Http2FrameCodec and Http2MultplexCodec which made it impossible to add special handling of frames before these are multiplexed to the Http2StreamChannels.

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 Http2FrameCodec and 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 HTTP/1 and HTTP/2: * 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

The old 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 DnsNameResolver.

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 socketChannelType:

DnsNameResolver resolver = new DnsNameResolverBuilder(eventLoop)
        .channelType(NioDatagramChannel.class)
        .socketChannelType(NioSocketChannel.class).build();
...

Thank You

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.