xh工具中--verify=no参数对重定向请求失效问题解析

问题背景

xh是一款基于Rust编写的现代化HTTP命令行工具，类似于curl但具有更友好的用户界面。近期用户反馈在使用xh工具时发现一个关于TLS证书验证的特殊情况：当使用--verify=no参数跳过TLS证书验证时，该设置仅对初始请求有效，而对后续的重定向请求无效。

问题复现

用户在使用xh 0.22.0版本时尝试访问一个HTTP端点，该端点会重定向到HTTPS地址。即使用户明确指定了--verify=no参数，xh工具仍然会对重定向后的HTTPS请求执行TLS证书验证，导致在遇到过期证书时请求失败。

技术分析

1. 参数传递机制缺陷：当前xh工具的实现中，TLS验证跳过设置(--verify=no)仅应用于初始请求，而未能正确传递到后续的重定向请求处理流程中。

2. 重定向处理逻辑：当服务器返回3xx重定向响应时，xh会创建新的请求实例，但在这个过程中未能继承原始请求的TLS验证配置。

3. 安全设计考量：虽然允许跳过证书验证在某些测试场景下很有用，但默认情况下保持严格的TLS验证是安全的最佳实践，这也是为什么这个问题可能未被及时发现的原因。

解决方案

1. 临时解决方案：用户可以直接指定HTTPS协议的目标URL，避免触发HTTP到HTTPS的重定向流程。例如：

   xh --verify=no https://example.com
   

2. 根本解决方案：需要修改xh的代码实现，确保所有请求选项(包括TLS验证设置)能够正确传递到重定向请求中。这涉及到：

   • 重定向处理器需要继承原始请求的配置
   • 对所有可能影响重定向请求的参数进行测试验证

扩展思考

这个问题提示我们在开发HTTP客户端工具时需要注意几个关键点：

1. 重定向处理应该完整保留原始请求的配置
2. 安全相关参数需要特别关注其作用范围
3. 对于链式请求(如重定向、认证等)，配置的传递机制需要统一设计

最佳实践建议

1. 在测试环境中使用--verify=no时，建议直接使用目标协议(HTTP/HTTPS)访问，避免重定向
2. 生产环境中不建议禁用证书验证，可以考虑使用--cert和--cert-key参数指定可信证书
3. 对于自动化脚本，建议明确指定完整的最终URL，减少对重定向的依赖

xh工具的开发团队已经确认这是一个需要修复的问题，预计在后续版本中会改进重定向请求的配置继承机制。