我试图确定客户端在从服务器接收303（请参阅其他）时应该使用标头做什么。具体来说，应该对初始请求发送的Authorization标头做什么？
问题在于：客户端向myserver.com发出请求（此处HTTP请求方法不相关），myserver.com的服务器响应303和{{1} } header包含Location。像Postman和curl这样的工具将遵循重定向，方法是将后续请求中的所有相同的标头传递给otherserver.com/some_resource/。我还没有办法让这些工具掉头。
在我所描述的情况下，将otherserver.com标题发送到Authorization似乎存在安全风险：otherserver.com现在知道我的令牌以及可能使用的主机现在，令牌已被泄露。这也可能导致错误，具体取决于目标主机的配置方式。如果重定向是相同主机上的其他资源（即otherserver.com），则myserver.com标头将（可能）需要发送，因为它＆ ＃39;同一个主机没有任何妥协。
实际上，在不同的情况下，似乎正确的行为是不同的。 RFC中的relevant section无法解决此问题。在开发自己的API时，我编写了文档，告诉API客户端在重定向到Authorization时删除Authorization标头。然而，基于curl和Postman的捣乱，我不清楚（a）典型HTTP客户端库的默认行为或（b）HTTP客户端库是否允许轻松修改HTTP头在303重定向之后之前。因此，我的建议可能不切实际。我也知道服务器无法指示客户端在执行303重定向时应该如何处理标题。
HTTP客户端在303重定向后应该如何处理标头？谁负责决定是否在重定向，HTTP客户端或服务器上使用相同的标头？
答案 0 :(得分：-1)
您可以争辩说，在发送带有otherserver.com位置的303时，myserver.com信任otherserver.com来处理您的令牌。它也可以在后台发送令牌。从客户端的角度来看，客户端信任myserver.com来处理令牌，安全地存储和验证令牌等。如果myserver.com决定将其发送到otherserver.com，客户端是否应该覆盖？在这种情况下它当然可以，但总的来说我认为不应该。
由于攻击者无法控制来自myserver.com的响应标头，这是一种合法资源，我认为通常将标记默认发送到它指定的其他服务器是安全的，可能除非你有一些好处理由不（说明客户的明确政策）。