Ansible URI模块处理相对重定向路径的缺陷分析

在Ansible自动化工具中，uri模块是用于HTTP/HTTPS请求的核心模块。近期发现该模块在处理服务器返回的相对路径重定向时存在逻辑缺陷，导致生成的目标地址不符合HTTP规范。本文将深入分析该问题的技术细节和影响范围。

问题现象

当使用uri模块请求一个会产生302重定向的URL时，如果服务器返回的是相对路径形式的重定向地址，模块会错误地将原始URL的查询参数拼接到新路径中。例如：

原始请求： http://httpbin.org/relative-redirect/1?foo=bar

服务器返回重定向到： /get

预期结果： http://httpbin.org/get

实际结果： http://httpbin.org?foo=bar/get

技术背景

HTTP协议中，重定向响应(3xx)的Location头部可以包含两种形式：

1. 绝对URL：包含完整协议、域名和路径
2. 相对路径：仅包含路径部分，需要客户端基于原始请求URL进行补全

RFC 3986规范明确了相对路径解析规则，要求客户端必须正确处理路径层级和查询参数的关系。在相对路径解析时，查询参数应当被新路径覆盖，而不是简单拼接。

问题根源

通过分析Ansible源码，发现uri模块在ansible/modules/uri.py中处理重定向时，直接使用了简单的字符串拼接逻辑：

location = original_url.split('?')[0] + location_header

这种实现方式没有考虑：

1. 路径规范化处理（去除多余的斜杠）
2. 查询参数的正确继承规则
3. URL各组成部分的边界判断

影响范围

该缺陷影响所有使用uri模块处理相对路径重定向的场景，特别是：

• 使用查询参数的API请求
• 多级路径的重定向
• 需要精确控制重定向目标的自动化流程

解决方案

正确的实现应该：

1. 使用标准库urllib.parse进行URL解析和重组
2. 遵循RFC 3986的相对路径解析规则
3. 正确处理查询参数的继承与覆盖

示例修复代码：

from urllib.parse import urlparse, urljoin

parsed_original = urlparse(original_url)
correct_location = urljoin(parsed_original.geturl(), location_header)

最佳实践建议

在修复版本发布前，用户可以：

1. 避免依赖uri模块的重定向处理，手动处理302响应
2. 确保服务端返回绝对路径形式的重定向地址
3. 对关键的重定向流程添加额外的验证断言

总结