Reactor-netty: Allow to set custom web-socket maxFramePayloadLength

Created on 21 Nov 2017  路  7Comments  路  Source: reactor/reactor-netty

Expected behavior

Web-socket connection is established

Actual behavior

HttpClientWSOperations use handshaker creation method with hard-coded maxFramePayloadLength instead of one that allows to specify custom max frame payload length.

As a result following exception is thrown in case server use frame length larger than 65536:
io.netty.handler.codec.CorruptedFrameException: Max frame length of 65536 has been exceeded. at io.netty.handler.codec.http.websocketx.WebSocket08FrameDecoder.protocolViolation(WebSocket08FrameDecoder.java:412) ~[netty-codec-http-4.1.16.Final.jar:4.1.16.Final] at io.netty.handler.codec.http.websocketx.WebSocket08FrameDecoder.decode(WebSocket08FrameDecoder.java:277) ~[netty-codec-http-4.1.16.Final.jar:4.1.16.Final] at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:489) ~[netty-codec-4.1.16.Final.jar:4.1.16.Final] at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:428) ~[netty-codec-4.1.16.Final.jar:4.1.16.Final] at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:265) ~[netty-codec-4.1.16.Final.jar:4.1.16.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362) [netty-transport-4.1.16.Final.jar:4.1.16.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348) [netty-transport-4.1.16.Final.jar:4.1.16.Final] at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340) [netty-transport-4.1.16.Final.jar:4.1.16.Final] at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1336) ~[netty-handler-4.1.16.Final.jar:4.1.16.Final] at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1127) ~[netty-handler-4.1.16.Final.jar:4.1.16.Final] at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1162) ~[netty-handler-4.1.16.Final.jar:4.1.16.Final] at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:489) ~[netty-codec-4.1.16.Final.jar:4.1.16.Final] at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:428) ~[netty-codec-4.1.16.Final.jar:4.1.16.Final] at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:265) ~[netty-codec-4.1.16.Final.jar:4.1.16.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362) [netty-transport-4.1.16.Final.jar:4.1.16.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348) [netty-transport-4.1.16.Final.jar:4.1.16.Final] at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340) [netty-transport-4.1.16.Final.jar:4.1.16.Final] at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1359) ~[netty-transport-4.1.16.Final.jar:4.1.16.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362) [netty-transport-4.1.16.Final.jar:4.1.16.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348) [netty-transport-4.1.16.Final.jar:4.1.16.Final] at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:935) ~[netty-transport-4.1.16.Final.jar:4.1.16.Final] at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:134) ~[netty-transport-4.1.16.Final.jar:4.1.16.Final] at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:645) ~[netty-transport-4.1.16.Final.jar:4.1.16.Final] at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:580) ~[netty-transport-4.1.16.Final.jar:4.1.16.Final] at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:497) ~[netty-transport-4.1.16.Final.jar:4.1.16.Final] at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:459) ~[netty-transport-4.1.16.Final.jar:4.1.16.Final]

Steps to reproduce

Connect to web-socket server that uses frame length larger than 65536

Reactor Netty version

0.7.1 RELEASE

JVM version (e.g. java -version)

1.8.0_131

OS version (e.g. uname -a)

Linux 2.6.32-573.8.1.el6.x86_64 x86_64 x86_64 x86_64 GNU/Linux

typenhancement

Most helpful comment

+1 .. I meant to raise this as well. There needs to be a way to configure WebSocket session related options. This is true for the server side as well.

We have similar options for Tomcat and Jetty but the Reactor Netty API does not expose it.

All 7 comments

+1 .. I meant to raise this as well. There needs to be a way to configure WebSocket session related options. This is true for the server side as well.

We have similar options for Tomcat and Jetty but the Reactor Netty API does not expose it.

This was also reported in the Spring Framework https://jira.spring.io/browse/SPR-16228.

Could this be included in 0.8 or 0.8 M2 ? We have it scheduled for Spring Framework 5.1 and it seems straight forward enough + fitting for the configuration API changes.

@violetagg, we also needs this for WebSocketServerHandshakerFactory based on SPR-16228. Do you want me to create a separate ticket for that?

Ping.

431 Isn't this what you need?

Oops, I missed that, thanks!

Was this page helpful?
0 / 5 - 0 ratings