Wrong websocket status code

Overview

I am trying to send a message larger than maxFrameSize to the server.However, the status code in the client close event is not WebSocketCloseStatus.MESSAGE_TOO_BIG

Client

let webSocket = new WebSocket('ws://localhost:1024/channel?_token=123456');
let count = 0;
webSocket.onopen = (event) => {
	console.log('连接打开', event);
	// Message length greater than 10 bytes
	let message = {
		'flag':count ++,
		'time':new Date().getTime()
	}
	webSocket.send(JSON.stringify(message))
}
webSocket.onclose = (event) => {
	console.log('连接断开', event);
}

ClonseEvent

Server

channelPipeline.addLast(new HttpServerCodec());
channelPipeline.addLast(new ChunkedWriteHandler());
channelPipeline.addLast(new HttpObjectAggregator(65536));
channelPipeline.addLast(new TokenValidateHandler(this.websocketPath));
channelPipeline.addLast(new WebSocketServerCompressionHandler());

// maxFrameSize = 10
channelPipeline.addLast(new WebSocketServerProtocolHandler(this.websocketPath, null, true, 10, false, true, true, 20000L));
channelPipeline.addLast(new HttpHandler());

//TODO 业务 handler，单独使用业务线程池
channelPipeline.addLast(new WebSocketFrameHandler());
channelPipeline.addLast(new ExceptionHandler());

Debug Info

It seems that the response to the client’s CloseWebSocketFrame is correct.

Exception Stack

io.netty.handler.codec.http.websocketx.CorruptedWebSocketFrameException: Max frame length of 10 has been exceeded.
	at io.netty.handler.codec.http.websocketx.WebSocket08FrameDecoder.protocolViolation(WebSocket08FrameDecoder.java:426)
	at io.netty.handler.codec.http.websocketx.WebSocket08FrameDecoder.decode(WebSocket08FrameDecoder.java:286)
	at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:500)
	at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:439)
	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:360)
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:352)
	at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1408)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:360)
	at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:930)
	at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:163)
	at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:697)
	at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:632)
	at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:549)
	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:511)
	at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:918)
	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	at java.lang.Thread.run(Thread.java:748)

Netty version

4.1.37.Final

[ursaj]

hi, @normanmaurer

as I remember - there is still a bug with handlers ordering and violation exceptions handling in WebSocket08FrameDecoder.protocolViolation():

    if (ctx.channel().isActive() && config.closeOnProtocolViolation()) {
        ...
        ctx
            .writeAndFlush(closeMessage) // Ignored
            .addListener(ChannelFutureListener.CLOSE); // Lead to abrupt channel close (1006)
    }
    throw ex;
}

Close message is NOT actually passed into encoder - encoder is higher in pipeline (see initialization in WebSocketServerHandshaker.handshake()). This is why close message is ignored and channel is closed abruptly (1006).

I did NOT find any proper solution for this bug (yet), so disabled this feature in my project through config:

config = WebSocketDecoderConfig.newBuilder()
    .closeOnProtocolViolation(false)

[amizurov]

@normanmaurer Thanks, work fine on our project.