springboot Restore TomcatReactiveWebServerFactoryTests

A recent Netty upgrade brings a change has highlighted a potential Tomcat bug.

TomcatReactiveWebServerFactoryTests now fails with the following:

java.lang.IllegalArgumentException: Both 'Content-Length: 3000' and 'Transfer-Encoding: chunked' found
    at io.netty.handler.codec.http.HttpObjectDecoder.readHeaders(HttpObjectDecoder.java:648) ~[netty-codec-http-4.1.44.Final.jar:4.1.44.Final]
    at io.netty.handler.codec.http.HttpObjectDecoder.decode(HttpObjectDecoder.java:218) ~[netty-codec-http-4.1.44.Final.jar:4.1.44.Final]
    at io.netty.handler.codec.http.HttpClientCodec$Decoder.decode(HttpClientCodec.java:202) ~[netty-codec-http-4.1.44.Final.jar:4.1.44.Final]
    at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:493) ~[netty-codec-4.1.44.Final.jar:4.1.44.Final]
    at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:432) ~[netty-codec-4.1.44.Final.jar:4.1.44.Final]
    at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:271) ~[netty-codec-4.1.44.Final.jar:4.1.44.Final]
    at io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:251) [netty-transport-4.1.44.Final.jar:4.1.44.Final]
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:377) [netty-transport-4.1.44.Final.jar:4.1.44.Final]
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:363) [netty-transport-4.1.44.Final.jar:4.1.44.Final]
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:355) [netty-transport-4.1.44.Final.jar:4.1.44.Final]
    at io.netty.handler.logging.LoggingHandler.channelRead(LoggingHandler.java:227) [netty-handler-4.1.44.Final.jar:4.1.44.Final]
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:377) [netty-transport-4.1.44.Final.jar:4.1.44.Final]
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:363) [netty-transport-4.1.44.Final.jar:4.1.44.Final]
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:355) [netty-transport-4.1.44.Final.jar:4.1.44.Final]
    at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410) [netty-transport-4.1.44.Final.jar:4.1.44.Final]
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:377) [netty-transport-4.1.44.Final.jar:4.1.44.Final]
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:363) [netty-transport-4.1.44.Final.jar:4.1.44.Final]
    at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919) [netty-transport-4.1.44.Final.jar:4.1.44.Final]
    at io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:792) [netty-transport-native-epoll-4.1.44.Final-linux-x86_64.jar:4.1.44.Final]
    at io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:475) [netty-transport-native-epoll-4.1.44.Final-linux-x86_64.jar:4.1.44.Final]
    at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378) [netty-transport-native-epoll-4.1.44.Final-linux-x86_64.jar:4.1.44.Final]
    at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989) [netty-common-4.1.44.Final.jar:4.1.44.Final]
    at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) [netty-common-4.1.44.Final.jar:4.1.44.Final]
    at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) [netty-common-4.1.44.Final.jar:4.1.44.Final]
    at java.lang.Thread.run(Thread.java:748) [na:1.8.0_232]

We need to either revert the upgrade or find a workaround.

Comment From: philwebb

I've disabled the tests for new. We'll need to revert 3fe4245ab66218a3bbaa7ca20e414acabb32dadf when we have a proper fix.

Comment From: wilkinsona

We need to either revert the upgrade or find a workaround.

The upgrade's accidental, unfortunately. We're still using 4.1.43 in spring-boot-dependencies, but Reactor Netty's transitive dependency on 4.1.44 is winning. 4.1.43 should be enforced, but I'm struggling to achieve that and publish Gradle module metadata that doesn't expose such strict requirements to consumers. I'm working with the Gradle team on it now. If push comes to shove, we can disable the publication of Gradle module metadata for M1 and switch back to using an enforced platform again.

Comment From: dreis2211

Adding this solely for a quick reference. The potential Tomcat bug turns out to be an issue in Spring-Framework: https://github.com/spring-projects/spring-framework/issues/24361

Comment From: wilkinsona

The ignores added in f73c4a837c721a967a541ec002d1c75f2bb7f181 will also need to be reverted.

Comment From: wilkinsona

As will the @Disabled tests added in https://github.com/spring-projects/spring-boot/commit/285ae01691435af138b2a6bbb6a37853391f6d75.