url片段和302redirect
众所周知，URL片段（ #之后的部分）不会被发送到服务器。
我不知道当涉及服务器redirect（通过HTTP状态302和Location:标头）时，碎片如何工作。
我的问题实际上是双重的：
-
如果原始URL有一个片段（
/original.php#foo），并且redirect到/new.php，原始URL的片段部分是否会丢失？ 或者它有时会被应用到新的URL？
在这种情况下，新的URL会是/new.php#foo吗？ -
无论原始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 。
