HTTP规范：代理授权和授权标头
所以我试图实现以下scheme：
- 应用程序受基本身份validation保护。 假设它在
app.com上app.com - 应用程序前面的HTTP代理也需要身份validation。 它在
proxy.com上proxy.com
因此，用户必须为同一请求中的代理和应用程序提供凭证，因此他具有不同的用户名/密码对：一对用于对该应用程序进行身份validation，另一个用户名/密码对以对代理进行身份validation。
在阅读规范后，我不太确定我应该如何实现这一点。 我想要做的是：
- 用户在没有任何authentication的情况下向代理发出HTTP请求。
- 代理服务器应答“
407 Proxy Authentication Required并以"Proxy-Authenticate: Basic realm="proxy.com"的格式返回Proxy-Authenticate标头。
问题 ：这个Proxy-Authenticate头是否正确设置？ - 客户端然后使用
Proxy-Authorization标头重试请求，即代理username:password的Base64表示。 - 这次代理validation请求，但是应用程序回答
401 Unauthorized头。 用户由代理进行了身份validation，但不是由应用程序进行身份validation。 该应用程序将WWW-Authenticate头添加到响应中，如WWW-Authenticate: Basic realm="app.com"。 问题 ：这个头值是正确的吗？ - 客户端再次重试该请求，同时使用
Proxy-Authorization标头和Authorization标头，该应用程序的username:password使用Base64表示。 - 此时，代理成功validation请求，并将请求转发给validation用户的应用程序。 客户终于得到回应。
整个工作stream程是否正确？
是的，这看起来像您描述的情况的一个有效的工作stream程，那些validation标题似乎是在正确的格式。
有趣的是，虽然不太可能，给定的连接可能涉及多个链接在一起的代理，并且每个代理本身都可能需要身份validation。 在这种情况下，每个中间代理的客户端将自己获得一个407 Proxy Authentication Required消息，并且自己用Proxy-Authorization头重复该请求; Proxy-Authenticate和Proxy-Authorization头是单跳头，不会从一个服务器传递到下一个，但是WWW-Authenticate和Authorization是端到端的头，被认为是从客户端到最终服务器，由中间人逐字传递。
由于Basicscheme在明文中发送密码（base64是可逆编码），因此它最常用于SSL。 这种情况是以不同的方式实现的，因为希望防止代理看到发送到最终服务器的密码：
- 客户端打开一个SSL通道到代理来发起请求，但是不是提交一个普通的HTTP请求，而是提交一个特殊的
CONNECT请求 （仍然带有一个Proxy-Authorization头）来打开到远程服务器的TCP隧道。 - 然后，客户端继续创build嵌套在第一个 SSL通道中的另一个 SSL通道，通过该通道传输包含
Authorization标头的最终HTTP消息。
在这种情况下，代理只知道客户端连接的主机和端口，而不知道通过内部SSL通道发送或接收的内容。 此外，使用嵌套通道允许客户端“查看”代理服务器和服务器的SSL证书，从而允许两者的身份validation。
