OpenShift环境.NET Core应用经WSO2调用报Socket Hangup错误咨询

问题根因梳理 #

首先明确报错的核心触发逻辑：
RFC 7231规范明确规定204 No Content响应不允许携带Content-Length头。IIS环境下会自动清理204响应的该头部，所以运行正常；但Kestrel默认不会做这个清理，返回204时仍然带了Content-Length: 0；而WSO2的passthru传输层处理响应时会默认给204响应自动添加Content-Length: 0头，两个重复头触发协议校验失败，WSO2直接关闭连接，就出现了前端访问的连接关闭报错、Postman调用的Socket Hang Up报错。

问题1：是否可以从响应中移除Content-Length头？ #

可以，这是最符合HTTP规范的修复方案，有两种实现方式：

1. 全局通用修复：添加ASP.NET Core中间件，统一处理所有204响应的头部清理
   示例代码：

   app.Use(async (context, next) =>
   {
       await next();
       if (context.Response.StatusCode == 204)
       {
           context.Response.Headers.Remove("Content-Length");
       }
   });
   

   注意要把这个中间件放在路由中间件之前，确保所有响应都能被处理。
2. 单接口针对性修复：修改当前接口的返回逻辑，返回null时手动处理响应头
   示例代码：

   [HttpGet("Settings/{identifier}/Timestamp")]
   public async Task<ActionResult<DateTimeOffset?>> MethodName(string identifier, CancellationToken token)
   {
       var res = await _service.MethodName(identifier, token);
       if (res == null)
       {
           Response.Headers.Remove("Content-Length");
           return NoContent();
       }
       return res;
   }
   

如果不方便修改后端代码，也可以调整WSO2的配置：在passthru-http.properties中开启http.headers.remove.duplicate.enable=true，自动清理重复响应头，但该方案会额外消耗WSO2的性能，优先级低于修改后端。

问题2：还有哪些可能的原因会引发该Socket Hangup错误？ #

除了上述的重复Content-Length头问题，还有以下常见触发原因：

• OpenShift路由（默认HAProxy）的空闲超时、响应超时配置短于WSO2端的超时时间，路由提前切断连接
• Kestrel的KeepAliveTimeout配置短于WSO2的连接保持时间，后端主动关闭未完成的连接
• OpenShift集群网络策略限制了WSO2到应用Pod的连接时长，空闲连接被集群网络组件强制切断
• 应用容器的CPU/内存资源配额不足，请求处理时出现CPU限流或者OOM Kill，内核主动断开TCP连接
• 响应存在其他不符合HTTP规范的头（比如非法字符、不允许重复的头字段重复出现），触发WSO2的协议校验失败断连
• WSO2和应用Pod之间的TLS证书不兼容、握手超时，导致SSL层提前中断连接

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