URL 片段和 302 重定向 [英] URL Fragment and 302 redirects

问题描述

众所周知，URL 片段(# 之后的部分)不会发送到服务器.

我确实想知道在涉及服务器重定向(通过 HTTP 状态 302 和 Location: 标头)时片段是如何工作的.

我的问题有两个方面:

1. 如果原始 URL 有一个片段 (/original.php#foo)，并且重定向到 /new.php，片段是否原始网址的一部分只是丢失了?或者它有时会应用于新的 URL?
   在这种情况下，新 URL 会是 /new.php#foo 吗?

2. 无论原始 URL 是什么，如果服务器重定向到带有片段 (/new.php#foo) 的新 URL，片段会得到尊重"吗?或者服务器真的没有任何业务干扰片段 - 因此浏览器会通过简单地转到 /new.php 来忽略它吗??

解决方案

2014 年 6 月 27 日更新:

RFC 7231，超文本传输​​协议 (HTTP/1.1):语义和内容, 已作为建议标准发布.来自变更日志:

<块引用>

Location 标头字段的语法已更改为允许所有URI 引用，包括相对引用和片段，以及对何时不使用片段进行了一些澄清合适的.(第 7.1.2 节)

第 7.1.2 节中的要点.位置:

<块引用>

如果 3xx(重定向)响应中提供的位置值没有片段组件，用户代理必须处理重定向就好像该值继承了 URI 的片段组件一样用于生成请求目标的引用(即重定向继承原始引用的片段(如果有)).

<块引用>

例如，一个为 URI 引用生成的 GET 请求http://www.example.org/~tim"可能会导致 303(见其他)包含标头字段的响应:

位置:/People.html#tim

这表明用户代理重定向到http://www.example.org/People.html#tim"

同样，为 URI 引用生成的 GET 请求http://www.example.org/index.html#larry"可能会导致 301 (Moved永久)包含标头字段的响应:

位置:http://www.example.net/index.html

这表明用户代理重定向到http://www.example.net/index.html#larry"，保留原文片段标识符.

这应该可以清楚地回答您的问题.

更新结束

这是当前 HTTP 规范的一个开放(未指定)问题.它在 IETF httpbis 工作组的 2 个问题中得到解决:

• #6:位置允许的片段
• #43:重定向期间的片段组合/优先级

#6 允许 Location 标头中的片段.#43 是这样说的:

<块引用>

我刚刚用各种浏览器对此进行了测试.

<块引用>

• Firefox 和 Safari 使用位置标头中的片段.
• Opera 使用来自源 URI 的片段(如果存在)，否则使用来自重定向位置的片段
• IE (8) 忽略位置 URI 中的片段，因此将使用来自源 URI 的片段(如果存在)

<块引用>

提案:

<块引用>

"注意:原始URI中的片段标识符和重定向需要组合时的行为未定义；当前的用户代理确实在哪个片段优先方面有所不同."

<块引用>

[...]

<块引用>

似乎 IE8 确实使用来自 Location 的片段标识符(我看到的行为可能仅限于 localhost).

<块引用>

因此，我们似乎对 Safari/IE/Firefox/Chrome(刚刚测试)具有一致的行为，因为无论原始 URI 是什么，都会使用 Location 标头中的片段.

<块引用>

因此，我更改了我的提议，以记录的预期行为.

这会导致最兼容浏览器和面向未来(因为这个问题最终会标准化)回答您的问题:

A:来自原始 URL 的片段被丢弃.

B: 来自 Location 标头的片段是有效的.

It's well known that the URL fragment (the part after the #) is not sent to the server.

I do wonder though how fragments work when a server redirect (via HTTP status 302 and Location: header) is involved.

My question is really two-fold:

1. If the original URL had a fragment (/original.php#foo), and a redirect is made to /new.php, does the fragment part of the original URL simply get lost? Or does it sometimes get applied to the new URL?
   Will the new URL ever be /new.php#foo in this case?

2. Regardless of the original URL, if the server redirects to a new URL with a fragment (/new.php#foo), will the fragment get "honored"? Or does the server really have no business interfering with the fragment at all -- and will the browser therefore ignore it by simply going to /new.php??

解决方案

Update 2014-Jun-27:

RFC 7231, Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content, has been published as a PROPOSED STANDARD. From the Changelog:

The syntax of the Location header field has been changed to allow all URI references, including relative references and fragments, along with some clarifications as to when use of fragments would not be appropriate. (Section 7.1.2)

The important points from Section 7.1.2. Location:

If the Location value provided in a 3xx (Redirection) response does not have a fragment component, a user agent MUST process the redirection as if the value inherits the fragment component of the URI reference used to generate the request target (i.e., the redirection inherits the original reference's fragment, if any).

For example, a GET request generated for the URI reference "http://www.example.org/~tim" might result in a 303 (See Other) response containing the header field:

Location: /People.html#tim

which suggests that the user agent redirect to "http://www.example.org/People.html#tim"

Likewise, a GET request generated for the URI reference "http://www.example.org/index.html#larry" might result in a 301 (Moved Permanently) response containing the header field:

Location: http://www.example.net/index.html

which suggests that the user agent redirect to "http://www.example.net/index.html#larry", preserving the original fragment identifier.

This should clearly answer your questions.

Update END

this is an open (not specified) issue with the current HTTP specification. it is addressed in 2 issues of the IETF httpbis working group:

• #6: Fragments allowed in Location
• #43: Fragment combination / precedence during redirects

#6 allows fragments in the Location header. #43 says this:

I just tested this with various browsers.

• Firefox and Safari use the fragment in the location header.
• Opera uses the fragment from the source URI, when present, otherwise the fragment from the redirect location
• IE (8) ignores the fragment in the location URI, thus will use the fragment from the source URI, when present

Proposal:

"Note: the behavior when fragment identifiers from the original URI and the redirect need to be combined is undefined; current User Agents indeed differ on what fragment takes precedence."

[...]

It appears that IE8 does use the fragment idenfitier from Location (the behavior I saw might be limited to localhost).

Thus we seem to have consistent behavior for Safari/IE/Firefox/Chrome (just tested), in that the fragment from the Location header gets used, no matter what the original URI was.

I therefore change my proposal to document that as expected behavior.

this leads to the most browser compatible and future proof (because this issue will eventually get standardized) answer to your question:

A: fragments from original URLs get discarded.

B: fragments from the Location header are honored.

这篇关于URL 片段和 302 重定向的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！