HTTP规格：代理授权和授权头

Question

所以我想实现以下情景：

• 的申请是由基本身份验证保护。假设它位于app.com
• 在应用程序前面的HTTP代理也需要身份验证。它是在proxy.com

托管因此，用户必须提供代理，并在同一个请求的应用既证书，他也因此有不同的用户名/密码对：一对，以验证自己对应用程序，而另一个用户名/密码对，以对代理进行身份验证。

阅读规范后，我不太确定我应该如何实现这一点。我想要做的是：

1. 用户向代理发出HTTP请求，而不进行任何类型的身份验证。
2. 代理回答407 Proxy Authentication Required，并返回Proxy-Authenticate标题，格式为："Proxy-Authenticate: Basic realm="proxy.com"。
   问题：这Proxy-Authenticate标题设置正确吗？
3. 客户端然后用Proxy-Authorization标题重试请求，即代理username:password的Base64表示。
4. 这次代理验证请求，但应用程序使用401 Unauthorized标题进行回答。用户由代理进行了身份验证，但不是由应用程序进行身份验证。该应用程序将一个WWW-Authenticate标题添加到响应中，如WWW-Authenticate: Basic realm="app.com"。 问题：此标题值是否正确？
5. 客户端再次尝试使用Proxy-Authorization标头和Authorization标头，并使用应用程序的username:password的Base64表示值重新发送请求。
6. 此时，代理成功验证请求，并将请求转发给验证用户的应用程序。客户终于得到回应。

整个工作流程是否正确？

Answer 1

是的，这看起来像您描述的情况的有效工作流程，并且这些验证标头似乎是正确的格式。

有趣的是，尽管不太可能，给定的连接可能涉及多个连接在一起的代理，并且每个代理本身都可能需要身份验证。在这种情况下，每个中间代理的客户端将自己获得一个407 Proxy Authentication Required消息，并且自己用Proxy-Authorization头重复该请求; Proxy-Authenticate和Proxy-Authorization标头是单跳标头，不会从一台服务器传递到下一台服务器，但WWW-Authenticate和Authorization是端到端标头，被认为是从客户端到最终服务器的端到端标头，通过逐字传递中介。

由于Basic方案在明文中发送密码（base64是一种可逆编码），因此它最常用于SSL。这种情况是以不同的方式实现的，因为希望防止代理看到发送到最终服务器的密码：

• 客户端打开一个到代理的SSL通道来发起请求，而不是提交一个普通的HTTP请求，它会提交a special CONNECT request（仍然带有一个Proxy-Authorization头）来打开到远程服务器的TCP隧道。
• 然后客户端继续创建另一个 SSL通道嵌套在第一个SSL通道中，通过它传输最终的HTTP消息，包括Authorization标头。

在这种情况下，代理只知道客户端连接到的主机和端口，而不知道通过内部SSL通道发送或接收的内容。此外，使用嵌套通道允许客户端“查看”代理服务器和服务器的SSL证书，从而允许两者的身份验证。