URL片段和302重定向

Question

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

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

我的问题实际上是双重的:

1. 如果原始URL有片段(/original.php#foo),并且进行了重定向/new.php,那么原始URL的片段部分是否会丢失？或者它有时会应用到新的URL？
   新的URL是否会出现/new.php#foo在这种情况下？

2. 无论原始URL如何,如果服务器重定向到带有fragment(/new.php#foo)的新URL,该片段是否会被"尊重"？或者服务器真的没有任何业务干扰片段 - 浏览器因此会忽略它只是去/new.php？

Answer 1

2014年6月27日更新:

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

Location头字段的语法已更改为允许所有URI引用,包括相对引用和片段,以及关于何时使用片段不合适的一些说明.(第7.1.2节)

从该重要点7.1.2节.位置:

如果在一个3XX(重定向)响应中提供的位置值不具有片段组件,用户代理必须处理该重定向仿佛值继承用于生成请求目标的URI引用的片段部分(即,重定向继承原始引用的片段,如果有的话).

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

Location: /People.html#tim

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

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

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

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

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

更新结束

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

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

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

我刚用各种浏览器测试过这个.

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

提案:

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

[...]

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

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

因此,我改变了我的建议记录是预期的行为.

这导致了大多数浏览器兼容和未来证明(因为这个问题最终会标准化)回答你的问题:

答:原始网址中的碎片会被丢弃.

B:Location标题中的片段受到尊重.

Answer 2

如果发生HTTP/3xx重定向,Safari 5和IE9及更低版本将丢弃原始URI的片段.如果响应上的Location标头指定了一个片段,则使用它.

IE10 +,Chrome 11 +,Firefox 4+和Opera将在执行3xx重定向后"重新附加"原始URI的片段.

测试页面:http://www.webdbg.com/test/redir/fragment/.

有关此问题的进一步讨论,请访问http://blogs.msdn.com/b/ieinternals/archive/2011/05/17/url-fragments-and-redirects-anchor-hash-missing.aspx

Answer 3

只是为了让您知道,在这里您可以找到合适的规格.通过w3c定义所有应该如何表现:http://www.w3.org/TR/cuap#uri - 第4.1条 - 见下文:

当资源(URI1)移动时,HTTP重定向可以指示其新位置(URI2).

如果URI1具有片段标识符#frag,那么用户代理应该尝试访问的新目标将是URI2#frag.如果URI2已经有片段标识符,则不得附加#frag,新目标为URI2.

错误:大多数当前用户代理确实实现了HTTP重定向,但是没有将片段标识符附加到新URI,这通常会使用户感到困惑,因为他们最终会得到错误的资源.

参考文献:

HTTP重定向在HTTP/1.1规范[RFC2616]的第10.3节中描述."重定向URL中的片段标识符的处理"[RURL]中详细描述了所需的行为.术语"持久统一资源定位符(PURL)"指定通过HTTP重定向指向另一个URL的URL(URI的特殊情况).有关更多信息,请参阅"持久统一资源定位器"[PURL].例:

假设用户在http://www.w3.org/TR/WD-ruby/#changes上请求资源, 服务器将用户代理重定向到http://www.w3.org/TR/ruby/.在获取后一个URI之前,浏览器应该将片段标识符#changes附加到它:http: //www.w3.org/TR/ruby/#changes.