URL 哈希在重定向之间持续存在答案

【问题标题】：URL hash is persisting between redirectsURL 哈希在重定向之间持续存在
【发布时间】：2011-07-14 02:15:22
【问题描述】：

由于某种原因，非 IE 浏览器在发送服务器端重定向（使用 Location 标头）时似乎会保留 URL 哈希（如果存在）。示例：

// a simple redirect using Response.Redirect("http://www.yahoo.com");
Text.aspx

如果我访问：

Test.aspx#foo

在 Firefox/Chrome 中，我被带到：

http://www.yahoo.com#foo

谁能解释为什么会这样？我也尝试过在不同平台上使用各种服务器端重定向（不过，所有这些都会导致 Location 标头），这似乎总是会发生。我在 HTTP 规范中的任何地方都没有看到它，但这似乎确实是浏览器本身的问题。 URL 哈希（如预期的那样）永远不会发送到服务器，因此服务器重定向不会被它污染，浏览器只是出于某种原因将其持久化。

有什么想法吗？

【问题讨论】：

URL Fragment and 302 redirects 解决了同样的问题。那里的答案很好。

标签： http url redirect hash fragment

【解决方案1】：

我认为这是正确的行为。 302 和 307 状态码表明该资源可以在别处找到。 #bookmark 是资源中的一个位置。

一旦找到资源（html 文档），浏览器就可以在文档中找到#bookmark。

类比是这样的：您想在第 57 章的书中查找某些内容，因此您去图书馆取书。但是书架上有一张纸条，上面写着这本书已经搬了，现在在另一栋楼里。所以你去新的位置。你仍然想要第 57 章——这与你从哪里得到这本书无关。

【讨论】：

您可以在 Location 标头中发送显式锚点。类似http://www.yahoo.com#
@Ben IE8 不使用哈希重定向。我希望它重定向。有什么想法吗？
@SanjeevKumarDangi - 你找到答案了吗，我也希望在 IE 中有解决方案？顺便说一句，IE9 也没有
@JustinBicknell，在 IE10 中测试，在重定向时保留哈希。
我认为这个类比不成立。这更像是：您想在第 57 章中查找某本书的内容，但是当您找到该书的第 57 章时，会有一条注释将您引导至另一本书。新书的第 57 章不太可能与原书的第 57 章相关。

【解决方案2】：

这是以前的 HTTP 规范未涵盖但 has been addressed in the later HTTP development 的一个方面：

如果服务器返回响应码300（“多选”），301 （“永久移动”）、302（“临时移动”）或 303（“见 other")，并且如果服务器还返回一个或多个 URI，其中可以找到资源，那么客户端应该将新的 URI 视为如果在末尾添加了原始 URI 的片段标识符。

例外情况是返回的 URI 已经有一个片段标识符。在这种情况下，原始片段标识符不得为未添加。

所以原始 URI 的片段也应该用于重定向 URI，除非它也包含片段。

虽然这只是 2000 年到期的草案，但似乎上述行为是当今网络浏览器中事实上的标准行为。

@Julian Reschke 或 @Mark Nottingham 可能对此了解更多/更好。

【讨论】：

绝不能添加到其中...如果这是标准的话，我们可怜:)

【解决方案3】：

根据我的发现，似乎并不清楚确切的行为应该是什么。有很多人对此有疑问，其中一些人希望通过重定向保留书签，另一些人希望摆脱它。

不同的浏览器处理这个问题的方式不同，因此在实践中依赖任何一种行为都没有用。

这绝对是浏览器问题。浏览器从不将 URL 的书签部分发送到服务器，因此服务器无法确定是否存在书签，也无法可靠地对其进行处理。

【讨论】：