libhv项目中WebSocket升级响应Content-Length处理机制解析

在libhv网络库的实际应用中，开发者发现当使用Nginx作为WebSocket中转服务时，服务器返回101状态码(协议切换响应)时会出现连接被意外关闭的问题。经过深入分析，这个问题源于HTTP升级响应中Content-Length头部的处理逻辑。

问题背景

WebSocket协议通过HTTP升级机制实现，服务器在同意升级时会返回101状态码。根据HTTP/1.1规范，这类响应通常不应该包含Content-Length头部，因为协议切换后传输的是WebSocket帧而非HTTP消息体。

在libhv的原始实现中，HttpMessage::FillContentLength()方法会无条件地为所有HTTP响应(包括101升级响应)添加Content-Length头部，即使其值为0。这违反了WebSocket协议规范，导致Nginx等严格遵循标准的转发服务错误地关闭了连接。

解决方案分析

正确的处理方式应该满足两个条件：

1. 对于普通HTTP响应，当内容长度不为0时，必须设置Content-Length
2. 对于协议升级响应(如WebSocket的101响应)，不应设置Content-Length头部

最终采用的解决方案是在FillContentLength()方法中增加对IsUpgrade()状态的检查，确保升级响应不会自动添加Content-Length头部。具体修改如下：

if (iter == headers.end() && !IsChunked() && content_type != TEXT_EVENT_STREAM) {
    if (content_length != 0 || (type == HTTP_RESPONSE && !IsUpgrade())) {
        headers["Content-Length"] = hv::to_string(content_length);
    }
}

这一修改既保持了原有功能，又正确处理了WebSocket升级场景，解决了与Nginx等转发服务的兼容性问题。

技术要点

1. HTTP协议升级机制：WebSocket通过在HTTP请求中包含"Upgrade: websocket"头部来启动协议切换，服务器同意后会返回101状态码。

2. Content-Length语义：该头部仅适用于有明确消息体的HTTP消息，对于没有消息体或使用分块传输编码的消息不应设置。

3. 转发服务行为：严格遵循标准的转发服务(如Nginx)会检查101响应的合规性，包含错误的Content-Length头部会导致连接终止。

这一改进体现了libhv项目对协议标准的严谨态度，确保了在各种部署环境下的稳定性和兼容性。开发者在使用libhv实现WebSocket服务时，可以放心地将其部署在反向中转后方，获得更好的可扩展性和安全性。