Netty WebSocket握手响应头部小写致旧客户端连接失败求助

我之前碰到过类似的老客户端兼容性问题，不用修改Netty源码就能解决，给你几个可行的方案：

1. 拦截响应并修改HTTP头部（最简单的方案） #

不需要改动现有握手逻辑，只需要在WebSocketServerProtocolHandler前添加一个自定义的ChannelInboundHandlerAdapter，拦截握手响应并修正头部名称的大小写。

这个思路的核心是：在Netty发送响应给客户端前，把小写的头部替换成旧客户端期望的首字母大写格式。

示例代码如下：

public class HttpHeaderCaseFixHandler extends ChannelInboundHandlerAdapter {
    @Override
    public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
        // 只处理WebSocket握手的HTTP响应
        if (msg instanceof FullHttpResponse) {
            FullHttpResponse response = (FullHttpResponse) msg;
            HttpHeaders headers = response.headers();
            
            // 替换特定头部的名称
            fixHeaderCase(headers, HttpHeaderNames.UPGRADE, "Upgrade");
            fixHeaderCase(headers, HttpHeaderNames.CONNECTION, "Connection");
            fixHeaderCase(headers, HttpHeaderNames.SEC_WEBSOCKET_ACCEPT, "Sec-WebSocket-Accept");
        }
        // 继续传递消息到下一个handler
        super.channelRead(ctx, msg);
    }

    private void fixHeaderCase(HttpHeaders headers, CharSequence originalName, String targetName) {
        CharSequence value = headers.get(originalName);
        if (value != null) {
            headers.remove(originalName);
            headers.set(targetName, value);
        }
    }
}

然后把这个handler插入到你的Pipeline中，位置在WebSocketServerProtocolHandler之前：

pipeline.addLast(new HttpServerCodec());
pipeline.addLast(new HttpObjectAggregator(65536));
pipeline.addLast(new HttpRequestBuilder());
// 插入自定义头部修正handler
pipeline.addLast(new HttpHeaderCaseFixHandler());
pipeline.addLast(new WebSocketServerProtocolHandler("/your-websocket-path"));
pipeline.addLast(new WebSocketFrameAggregator(65536));
pipeline.addLast(new CustomHandler());

2. 自定义WebSocket握手器（更彻底的方案） #

如果想从握手逻辑层面解决，可以继承WebSocketServerHandshaker13，重写newHandshakeResponse方法，直接生成符合要求的头部格式。

示例代码：

public class CaseCorrectWebSocketHandshaker13 extends WebSocketServerHandshaker13 {
    public CaseCorrectWebSocketHandshaker13(String webSocketURL, String subprotocols, boolean allowExtensions, int maxFramePayloadLength) {
        super(webSocketURL, subprotocols, allowExtensions, maxFramePayloadLength);
    }

    @Override
    public FullHttpResponse newHandshakeResponse(FullHttpRequest req, HttpHeaders headers) {
        FullHttpResponse response = super.newHandshakeResponse(req, headers);
        // 直接覆盖头部名称为正确的大小写
        response.headers().set("Upgrade", response.headers().get(HttpHeaderNames.UPGRADE));
        response.headers().set("Connection", response.headers().get(HttpHeaderNames.CONNECTION));
        response.headers().set("Sec-WebSocket-Accept", response.headers().get(HttpHeaderNames.SEC_WEBSOCKET_ACCEPT));
        // 移除原有的小写头部
        response.headers().remove(HttpHeaderNames.UPGRADE);
        response.headers().remove(HttpHeaderNames.CONNECTION);
        response.headers().remove(HttpHeaderNames.SEC_WEBSOCKET_ACCEPT);
        return response;
    }
}

之后在初始化Channel时，替换默认的握手器：

pipeline.addLast(new SimpleChannelInboundHandler<FullHttpRequest>() {
    @Override
    protected void channelRead0(ChannelHandlerContext ctx, FullHttpRequest req) throws Exception {
        if (WebSocketServerProtocolHandler.isWebSocketUpgrade(req)) {
            // 使用自定义握手器
            CaseCorrectWebSocketHandshaker13 handshaker = new CaseCorrectWebSocketHandshaker13(
                    "ws://your-domain:port/path", null, true, 65536);
            ChannelFuture handshakeFuture = handshaker.handshake(ctx.channel(), req);
            handshakeFuture.addListener(future -> {
                if (future.isSuccess()) {
                    ctx.fireChannelRead(req.retain());
                }
            });
            // 移除当前handler，避免重复处理
            ctx.pipeline().remove(this);
        } else {
            ctx.fireChannelRead(req);
        }
    }
});
// 后续添加WebSocketServerProtocolHandler等其他handler

3. 无需自定义WebSocketServerProtocolHandler #

完全不需要重写WebSocketServerProtocolHandler，上面两种方案都能基于现有组件实现兼容，没必要额外自定义这个核心handler，反而会增加维护成本。

总结 #

最推荐第一种方案：轻量、侵入性低，只需要在Pipeline中插入一个小handler就能解决问题，不需要改动原有WebSocket的核心逻辑。

内容的提问来源于stack exchange，提问作者ssen