我正在尝试确定客户端在从服务器接收到 303（请参阅其他）时应如何处理标头。具体来说，应该如何Authorization处理在初始请求中发送的标头？
这就是问题所在：客户端发出请求myserver.com（HTTP 请求方法在此不相关），并且服务器以myserver.com303 响应，并且Location标头包含otherserver.com/some_resource/. Postman 和 curl 等工具将通过将后续请求中的所有相同otherserver.com标头传递给. 我还没有找到让这些工具删除标题的方法。
在我所描述的情况下，将Authorization标头发送到otherserver.com似乎存在安全风险：otherserver.com现在知道我的令牌以及它可以在哪个主机上使用，所以现在令牌已被泄露。这也可能导致错误，具体取决于目标主机的配置方式。如果重定向到同一主机上的另一个资源（即myserver.com），那么Authorization标头将（可能）需要发送，并且因为它是同一主机，所以没有任何损害。
实际上，在不同的情况下，正确的行为似乎是不同的。RFC 中的相关部分未解决此问题。在开发我自己的 API 时，我编写了文档告诉 API 客户端将Authorization标头放在重定向到otherserver.com. 但是，基于对 curl 和 Postman 的处理，我不清楚 (a) 典型 HTTP 客户端库的默认行为是什么，或者 (b) HTTP 客户端库是否允许在遵循 303之前轻松修改 HTTP 标头重定向。因此，我的建议可能不切实际。我也知道服务器无法指示客户端在遵循 303 重定向时应该如何处理标头。
当 HTTP 客户端遵循 303 重定向时，它应该如何处理标头？谁负责决定是否在重定向、HTTP 客户端或服务器上使用相同的标头？