先给你掰清楚规范要求、实际工具的行为差异，再说说开发客户端时该怎么搞：

从HTTP规范的角度说 #

根据HTTP/1.1的官方规范，303响应的核心意图是让客户端改用GET方法去请求Location里指定的资源。而关键的安全点在于：如果重定向的目标是跨域地址（比如你例子里从myserver.com跳到otherserver.com），绝对不能自动把原请求里的Authorization头部带过去。毕竟，你肯定不想把发给A服务器的身份凭证，平白无故送到完全无关的B服务器手里，这可是严重的安全风险。

实际工具的行为差异 #

不同工具对这个规则的实现不太一样，咱们拿你提到的curl和Postman举例：

• curl：默认情况下，curl在跟随跨域303重定向时，不会自动传递Authorization头部。只有当你显式加上--location-trusted参数时，它才会把凭证带到目标域名。比如：

  # 默认安全行为：不把Authorization传给otherserver.com
  curl -H "Authorization: Bearer xxx" -L https://myserver.com/endpoint
  
  # 主动选择传递凭证（仅在你完全信任目标服务器时用）
  curl -H "Authorization: Bearer xxx" -L --location-trusted https://myserver.com/endpoint
  

• Postman：Postman默认会在跟随重定向时保留所有请求头部，包括Authorization。不过你可以手动调整这个设置：进入「Settings」→「General」，找到「Automatically follow redirects」下方的「Preserve authorization headers when following redirects」选项，取消勾选就能遵循规范的安全要求。

客户端开发的最佳实践 #

如果你自己开发客户端，记住这几个原则：

• 跨域重定向：坚决不自动携带Authorization头部，这是安全红线。如果目标资源确实需要验证，应该引导用户手动授权，或者通过更安全的方式（比如跳转前的凭证交换流程）来处理。
• 同域重定向：如果目标地址和原请求在同一个域名下，你可以选择携带Authorization，但也要确认这个重定向是合法预期的，避免CSRF之类的风险。
• 给用户选择权：像curl和Postman那样，提供配置开关让用户决定是否携带敏感头部，别默认强制传递，把控制权交给使用者。

内容的提问来源于stack exchange，提问作者Paul Holden