当客户端包含用户名&时,客户端如何处理HTTP响应中的位置字段?密码?

时间:2013-03-08 21:36:10

标签: http http-headers httpresponse

规范未提及如何处理用户名:位置返回的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.

1 个答案:

答案 0 :(得分: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标题实际上根本不应包含user:secret@部分,只是您给出的示例网址的其余部分,以及您(客户端)将负责记住您在重定向的原始请求的Authorization标头中发送的用户/通行证,并在第二个请求中再次传递相同的标头。

<强>更新

此外,RFC 2396 section 3.2.2还有一些关于在网址中使用用户/密码的说法:

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.