url片段和302redirect

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

我不知道当涉及服务器redirect(通过HTTP状态302和Location:标头)时,碎片如何工作。

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

  1. 如果原始URL有一个片段( /original.php#foo ),并且redirect到/new.php ,原始URL的片段部分是否会丢失? 或者它有时会被应用到新的URL?
    在这种情况下,新的URL会是/new.php#foo吗?

  2. 无论原始URL如何,如果服务器redirect到一个带有片段( /new.php#foo )的新URL,该片段/new.php#foo会被“尊重”? 或者,服务器真的没有干扰片段的业务 – 所以浏览器会忽略它,只需去/new.php

更新2014年6月27日

RFC 7231超文本传输​​协议(HTTP / 1.1):语义和内容已经作为build议标准发布。 从更新日志 :

Location头域的语法已经被改变,以允许所有URI引用,包括相对引用和片段,以及关于什么时候使用片段不合适的一些说明。 (第7.1.2节)

7.1.2节的重点。 位置 :

如果3xx(redirect)响应中提供的位置值没有分片组件,则用户代理必须处理redirect,就好像该值inheritance用于生成请求目标的URI引用的片段组件(即,redirectinheritance原始引用的片段,如果有的话)。

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

 Location: /People.html#tim 

这表明用户代理redirect到“ http://www.example.org/People.html#tim

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

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

这表明用户代理redirect到“ http://www.example.net/index.html#larry ”,保留原始的片段标识符。

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

更新END

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

  • #6: 位置允许的碎片
  • #43: redirect期间的碎片组合/优先顺序

#6允许Location标题中的片段。 #43说这个:

我只是用各种浏览器testing了这个。

  • Firefox和Safari使用位置标题中的片段。
  • Opera使用来自源URI的片段(当存在时),否则使用来自redirect位置的片段
  • IE(8)忽略位置URI中的片段,因此当存在时将使用来自源URI的片段

提案:

“注意:原始URI和redirect需要合并的片段标识符时的行为是未定义的;当前用户代理实际上在片段优先级上是不同的。

[…]

看来,IE8 确实使用了Location的片段标识符(我看到的行为可能仅限于本地主机)。

因此,我们似乎对Safari / IE / Firefox / Chrome(刚刚testing)具有一致的行为,因为无论原始URI是什么,Location标头中的片段都可以使用。

因此,我改变了我的build议,logging下如预期的行为。

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

答:原始url的片段会被丢弃。

B:来自Location标题的片段得到遵守。

如果发生HTTP / 3xxredirect,则Safari 5和IE9及以下版本将删除原始URI的片段。 如果响应的位置标题指定了一个片段,则使用它。

IE10 +,Chrome 11 +,Firefox 4+和Opera将在3xxredirect之后“重新连接”原始URI的片段。

testing页面: 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

只是为了让你知道,在这里你可以find适当的规格。 由W3C定义所有应该如何performance: http : //www.w3.org/TR/cuap#uri – 第4.1条 – 见下文:

当资源(URI1)移动时,HTTPredirect可以指示其新的位置(URI2)。

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

错误:大多数当前的用户代理确实实现了HTTPredirect,但是不把这个片段标识符附加到新的URI上,这通常会导致用户混淆,因为他们最终会得到错误的资源。

参考文献:

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

假设用户请求http://www.w3.org/TR/WD-ruby/#changes处的资源,服务器将用户代理redirect到http://www.w3.org/TR/ruby/ 。 在获取后一个URI之前,浏览器应该在其中添加片段标识符#changes: http : //www.w3.org/TR/ruby/#changes 。