URL哈希在重定向之间保持不变

Question

由于某些原因，非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哈希（如预期的那样）永远不会发送到服务器，因此服务器重定向不会被其污染，浏览器似乎只是出于某种原因将其保留。

有任何想法吗？

- chinabuffet

---

同样的问题在URL片段和302重定向中得到了解决。那里有很好的答案。 - Palec

Answer 1

我建议这是正确的行为。302和307状态代码表明资源应该在其他地方找到。#bookmark是资源中的位置。

一旦定位了资源（HTML文档），浏览器就会定位文档内的#bookmark。

类比如下：您想在第57章的书中查找某些内容，因此去图书馆借书。但是书架上有一个提示说明书已经移动，现在在另一个建筑物里。所以您去新的位置。您仍然需要第57章 - 您得到书的地方无关紧要。

- Ben

---

你可以在“Location”头部中发送一个明确的锚点。例如，像这样：http://www.yahoo.com# - Holger Just

@Ben IE8不会重定向带有哈希的链接。我想让它重定向，有什么建议吗？ - Sanjeev Kumar Dangi

@SanjeevKumarDangi - 你找到了答案吗？我也希望在IE中有解决方案。顺便说一句，IE9也没有解决这个问题。 - Justin Bicknell

@JustinBicknell，在IE10中进行了测试，重定向时保留了哈希值。 - Ben

我认为这个比喻不太恰当。更像是：你想在第57章的书中查找某些内容，但当你找到这本书的第57章时，却发现有一个注释指向另一本书。新书的第57章不太可能与原书的第57章相关。 - Thomas Higginbotham

Answer 2

这是以前的HTTP规范没有涉及到的一个方面，但是在后来的HTTP开发中得到了解决：

如果服务器返回300（“多种选择”）、301（“永久移动”）、302（“暂时移动”）或303（“查看其他”）响应代码，并且服务器还返回一个或多个URI，其中可以找到资源，则客户端应将新URI视为原始URI的片段标识符添加到末尾。

例外情况是当返回的URI已经有一个片段标识符时。在这种情况下，原始片段标识符不应被添加到其中。

因此，除非重定向URI也包含片段，否则应该使用原始URI的片段进行重定向。

虽然这只是一个于2000年过期的草案，但似乎上述行为在今天的Web浏览器中是事实上的标准行为。 @Julian Reschke 或 @Mark Nottingham 可能更了解/更好地了解这一点。

- Gumbo

---

不得向其中添加任何东西...如果那是标准，我们就太惨了 :) - user6110389

Answer 3

根据我的研究，似乎没有确定应该是什么确切行为。很多人都遇到了这个问题，其中一些人希望通过重定向保留书签，而另一些人则想摆脱它。

不同的浏览器处理此问题的方式也不同，因此实际上依赖任何一种行为都没有用。

这绝对是一个浏览器问题。浏览器从不将URL的书签部分发送到服务器，因此服务器无法找出是否有书签存在，也无法可靠地处理该问题。

- Guffa

Answer 4

当我将完整的URL放在表单的action属性中时，它会保留hash。但是如果只使用查询字符串，则会删除hash。例如，

保留hash:

https://example.com/edit#alrighty

<form action="https://example.com/edit?ok=yes">

删除 hash：

https://example.com/edit

<form action="?ok=yes">

- Jon49