Deploy API的URL编码异常问题排查与解决请求

问题详情 #

• API地址：*******/api/3-1-app-313a04d4-e556-4dc7-b90a-1a1d0b347368/deploy
• 预期行为：首次请求返回202状态码，二次请求返回303状态码
• 实际异常：二次请求触发404错误，日志显示URL被附加多余的%3C和%3E（即<和>的URL编码）；偶尔重试可正常返回202
• 环境差异：浏览器、Postman中二次请求必现404，curl工具两次请求均成功

各工具响应信息 #

curl响应信息 #

HTTP/2 202 
server: openresty/1.21.4.1
date: Mon, 16 Dec 2024 12:20:13 GMT
content-type: text/html; charset=utf-8
content-length: 44
location: /***/***/242407/status

{"message": "deploy scheduled successfully"}% , 


HTTP/2 303 
server: openresty/1.21.4.1
date: Mon, 16 Dec 2024 12:20:29 GMT
content-type: text/html; charset=utf-8
content-length: 43
location: /***/***/242407/status , 

Postman响应信息 #

{"message": "deploy scheduled successfully"} ,
404 Not Found

排查方向建议 #

• 客户端自动转义问题：检查浏览器/Postman是否对首次请求返回的location头部进行了错误二次编码。若服务端返回的location包含特殊字符，客户端可能误将其标记为需要转义的内容，导致二次请求URL被附加%3C/%3E。
• 服务端location格式校验：对比curl与Postman收到的location头部细节，确认服务端返回的重定向地址是否存在格式异常（如多余符号、空格）。curl对头部容错性更强，而浏览器/Postman的解析逻辑更严格，微小格式问题可能引发URL篡改。
• 自动重定向逻辑差异：浏览器和Postman默认自动处理303重定向，而curl默认不跟随重定向。确认二次请求是否为客户端自动发起的重定向请求，而非手动构造地址，排查自动重定向过程中是否出现URL篡改。
• 缓存/会话干扰：浏览器和Postman可能缓存了错误的URL或会话状态，导致二次请求复用异常地址。尝试清除缓存、新建会话后重新测试。
• URL解析库差异：不同工具依赖的URL解析库逻辑不同，curl的解析规则更宽松，而浏览器/Postman的库对格式要求更严格，服务端返回的location若存在非标准格式，可能触发后者解析错误。

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