HttpWebRequest无法可靠发送JSESSIONID Cookie问题排查

问题背景 #

脚本与第三方网站n.server.com交互已正常运行十余年，近期出现异常：使用HttpWebRequest发送请求时，路径为/Am的JSESSIONID Cookie可在首次POST和PUT请求中正常发送，但第二次调用同一PUT URL（仅请求体不同）时，该Cookie不再被携带。将Cookie路径改为/后，问题消失。已排除域名（www有无）、协议（http/https）变更因素。

Cookie属性如下：

Name: JSESSIONID
Value: [snip]  
Domain: n.server.com  
Path: /Am  
Secure: True  
Http only: True  
Expires: 0001-01-01 00:00:00  
Expired: False

正常发送Cookie的请求示例：

POST https://n.server.com/Am/Fq/Pi
PUT  https://n.server.com/Am/Fq/P/D

可能原因 #

1. HttpWebRequest CookieContainer的会话Cookie管理bug
   由于该Cookie为会话级（Expires设为0001-01-01），HttpWebRequest的CookieContainer在处理重复URL的请求时，可能错误触发会话Cookie的内部回收逻辑，导致路径为/Am的Cookie被标记为不可用。而路径为/的Cookie因匹配范围更广，未触发此逻辑。

2. 第三方网站的Cookie规则变更
   第三方网站近期可能调整了：

   • 服务器端的Cookie路径匹配规则，对/Am前缀的路径匹配做了更严格的校验（比如尾部斜杠、大小写敏感性处理）；
   • 在首次PUT请求的响应中返回新的Set-Cookie头，覆盖了原有JSESSIONID的路径（比如设置为更具体的路径），导致第二次请求携带的Cookie不符合服务器要求。

3. HttpWebRequest路径匹配的边缘场景问题
   HttpWebRequest对Cookie路径的匹配逻辑可能存在场景漏洞：当请求URL的路径层级较深（如/Am/Fq/P/D）时，多次请求后容器可能错误判断该路径不属于/Am的前缀范围，而路径改为/后则无此问题。

解决方案 #

1. 固化Cookie路径为/的修复逻辑
   既然修改路径为/可解决问题，可在获取到初始JSESSIONID后，手动重新创建Cookie并替换原有Cookie：

   // 假设已从响应中获取到原始Cookie
   Cookie originalCookie = ...;
   // 创建新Cookie，路径改为/
   Cookie fixedCookie = new Cookie(originalCookie.Name, originalCookie.Value, "/", originalCookie.Domain);
   fixedCookie.Secure = originalCookie.Secure;
   fixedCookie.HttpOnly = originalCookie.HttpOnly;
   // 添加到CookieContainer，覆盖原有路径的Cookie
   cookieContainer.Add(fixedCookie);
   

2. 检查响应中的Set-Cookie头
   捕获首次PUT请求的响应头，查看是否存在新的Set-Cookie字段，若发现网站返回了路径异常的JSESSIONID，可在代码中过滤此类响应头，避免覆盖原有有效Cookie。

3. 替换为HttpClient
   HttpWebRequest是.NET Framework中的旧API，后续维护较少。改用HttpClient（其Cookie处理基于HttpClientHandler的CookieContainer），可避免旧API的会话Cookie管理bug，提升稳定性。

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