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):语义和内容作为建议标准发布.从更改日志:

位置"标头字段的语法已更改为允许所有 URI参考，包括相对参考和片段 关于何时使用片段的一些澄清 合适的. (第7.1.2节)

第7.1.2节中的要点.位置:

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

例如，一个 为URI参考生成的GET请求 " http://www.example.org/~tim "可能会显示303(请参阅其他) 包含标题字段的响应:

Location: /People.html#tim

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

同样，为URI参考生成了GET请求 可能会导致" http://www.example.org/index.html#larry "在301(已移动 永久)包含标题字段的响应:

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

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

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

更新END

这是当前HTTP规范的未解决(未指定)问题. IETF httpbis工作组的2个问题中对此进行了处理:

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

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

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

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

建议:

注意:当需要合并来自原始URI和重定向的片段标识符时的行为是不确定的；当前的用户代理确实在哪个片段优先上有所不同."

[...]

似乎IE8 确实使用了Location中的片段idenfitier(我看到的行为可能仅限于本地主机).

因此，对于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屋！