http - 当包含用户名和密码时，客户端应如何处理 HTTP 响应中的 Location 字段？

Question

规范没有提及如何处理 Location 返回的 URI 中的用户名:密码，例如:

Location: http://user:secret@w3.org/hidden/pages

我们应该忽略这些吗？这似乎没有意义，但我想知道如果它发生了怎么办(即服务器配置错误，某些管理员/程序员的奇怪想法...... .)

14.30 Location

The Location response-header field is used to redirect the recipient
to a location other than the Request-URI for completion of the request
or identification of a new resource. For 201 (Created) responses, the
Location is that of the new resource which was created by the request.
For 3xx responses, the location SHOULD indicate the server's preferred
URI for automatic redirection to the resource. The field value
consists of a single absolute URI.

       Location       = "Location" ":" absoluteURI

An example is:

       Location: http://www.w3.org/pub/WWW/People.html

      Note: The Content-Location header field (section 14.14) differs
      from Location in that the Content-Location identifies the original
      location of the entity enclosed in the request. It is therefore
      possible for a response to contain header fields for both Location
      and Content-Location. Also see section 13.10 for cache
      requirements of some methods.

Answer 1

RFC 2617可能会有答案。来自 section 3.3 :

...For example
a server could be responsible for authenticating content that
actually sits on another server. It would achieve this by having the
first 401 response include a domain directive whose value includes a
URI on the second server, and an opaque directive whose value
contains the state information. The client will retry the request, at
which time the server might respond with a 301/302 redirection,
pointing to the URI on the second server. The client will follow the
redirection, and pass an Authorization header , including the
<opaque> data.

所以我将其解释为您从 HTTP 重定向返回的 Location header 实际上根本不应该包含 user:secret@ 部分，而只是您提供的示例 URL 的其余部分，并且您(客户端)将负责记住您在重定向的原始请求的 Authorization header 中发送的用户/密码，并传递相同的在第二个请求中再次 header 。

更新

此外，RFC 2396 section 3.2.2有一些关于在 URL 中使用用户名/密码的话:

Some URL schemes use the format "user:password" in the userinfo
field. This practice is NOT RECOMMENDED, because the passing of
authentication information in clear text (such as URI) has proven to
be a security risk in almost every case where it has been used.