http - 浏览器未将在深层 URL 上设置的 `Authorization` header 发送到根 URL

Question

当我在某个 URL 向用户请求 HTTP 基本身份验证时，浏览器仅为该 URL 和其他一些 URL 发送 Authorization header 。

用 PHP 编写的测试用例脚本: http://testauth.veadev.tk/

可以使用三个 URL 来请求凭据(您可以使用任意一个)。 注销链接(在浏览器身份验证表单中按下“取消”按钮后删除当前凭据，在 IE 中不起作用)。 指向根 URL 和一些测试更深层 URL 的链接。

问题:

1. 如果 HTTP/1.0 401 Unauthorized 在 /system 发送，为什么浏览器不在 / URL 发送 Authorization header /开发？ 重复:打开干净http://testauth.veadev.tk/ , 单击 Auth2，输入任何凭据，之后您将被转发到 /。您将看到 Auth: null，这意味着浏览器未发送凭据 header 。

2. 如果 HTTP/1.0 401 Unauthorized 在 /dev< 发送，为什么浏览器在 / 发送 Authorization header ？ 重复:打开干净http://testauth.veadev.tk/ , 单击 Auth1，输入任何凭据，之后您将被转发到 /。您会看到类似 Auth: string 'Basic dHQ6dHQ=' (length=14) 的内容，这意味着凭据 header 已由浏览器发送。

3. 如果您重复第一种情况，然后单击 Auth1，您将在 Root 和所有其他页面获得凭据。为什么？

4. 如果您点击 Auth3 (/some/deep/and/long/url)，您将在 Page3 (/some/deep/and/long/3) 而别处。为什么？

要清除测试之间的凭据状态，请重新启动浏览器或单击Logout，在 Auth 表单中单击Cancel，然后单击 Root 返回(Firefox，谷歌浏览器)。

发送Authorization头的规则是什么？

Answer 1

RFC 2617 ，第 2 节指出:

A client SHOULD assume that all paths at or deeper than the depth of the last symbolic element in the path field of the Request-URI also are within the protection space specified by the Basic realm value of the current challenge. A client MAY preemptively send the corresponding Authorization header with requests for resources in that space without receipt of another challenge from the server.

如果您正在使用 Digest Challenge，第 3.2 节指出您可以在 WWW-Authenticate header 中指定一个 domain 以指示保护空间是什么。我会尝试将其设置为类似 domain=/ 的内容。我不确定这是否适用于基本授权，但尝试一下不会有什么坏处；否则，摘要授权的使用难度不会大多少，而且更安全一些。