如何从Location头构造URI？

Question

对“http://fakedomain.com/my/abc/redirect.php?url=www.example.com”URL的GET请求导致以下响应头，

HTTP/1.1 302 Found
Date: Mon, 30 Apr 2018 07:39:12 GMT
Server: Apache/2.2.15 (CentOS)
X-Powered-By: PHP/5.3.3
Location: www.example.com
Content-Length: 40
Connection: close
Content-Type: text/html; charset=UTF-8

服务器如何准备/用户代理从此位置标头准备URL。

它是否向“www.example.com”发送重定向请求？或者它是否向“http://fakedomain.com/my/abc/www.example.com”发送重定向请求？

为什么它会像这样构建URL？

Answer 1

它是否向www.example.com发送重定向请求？或者它是否向http://fakedomain.com/my/abc/www.example.com发送重定向请求？

该请求应重定向到http://fakedomain.com/my/abc/www.example.com。

RFC 7231说关于Location标题的以下内容（亮点是我的）：

7.1.2. Location

Location头字段在某些响应中用于指代与响应相关的特定资源。关系类型由请求方法和状态代码语义的组合定义。

 Location = URI-reference

字段值由单个URI引用组成。 [...]

URI-reference概念在RFC 3986中定义如下（突出显示是我的）：

4.1. URI Reference

URI-reference用于表示资源标识符的最常见用法。

 URI-reference = URI / relative-ref

URI引用是URI或相对引用。如果URI-reference的前缀与其冒号分隔符后面的方案的语法不匹配，则URI-reference是相对引用。 [...]

所以www.example.com应该被解释为relative reference而不是absolute URI。

www.example.com情况在suffix reference中被描述为RFC 3986：它具有与相对路径引用相同的语法，并且不能在期望相对引用的上下文中使用（突出显示是我的）：

4.5. Suffix Reference

URI语法旨在通过URI方案明确引用资源和可扩展性。然而，随着URI识别和使用变得普遍，传统媒体（电视，广播，报纸，广告牌等）越来越多地使用URI的后缀作为参考，仅由URI的权限和路径部分组成，例如如

 www.w3.org/Addressing/

或者只是一个DNS注册名称。这些引用主要用于人类解释而不是机器，假设基于上下文的启发式方法足以完成URI（例如，以www开头的大多数注册名称可能具有http://的URI前缀）。虽然没有标准的启发式方法来消除URI后缀的歧义，但许多客户端实现允许用户输入并启发式解析。

尽管这种使用后缀引用的做法很常见，但应尽可能避免使用后缀，并且绝不应在需要长期引用的情况下使用。上面提到的启发式方法将随着时间的推移而改变，特别是当新的URI方案变得流行时，并且当在上下文之外使用时通常是不正确的。 [...]

由于URI后缀与相对路径引用具有相同的语法，因此后缀引用不能用于需要相对引用的上下文中。因此，后缀引用仅限于没有定义基URI的位置，例如对话框和离线广告。