出于某种原因，非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哈希（如预期的那样）永远不会发送到服务器，因此服务器重定向不会被它污染，浏览器只是出于某种原因而持久化。
有什么想法吗？
答案 0 :(得分：73)
我建议这是正确的行为。 302和307状态代码表示资源可在其他地方找到。 #bookmark是资源中的一个位置。
找到资源（html文档）后，浏览器可以在文档中找到#bookmark。
这个比喻是这样的：你想在第57章的书中看一些东西，所以你去图书馆拿到这本书。但是书架上有一张纸条说这本书已经移动了，它现在在另一栋楼里。所以你去了新的位置。你仍然想要第57章 - 你得到这本书的地方无关紧要。
答案 1 :(得分：24)
这是以前的HTTP规范未涵盖的方面，但has been addressed in the later HTTP development：
如果服务器返回响应代码300（“多选”），则301 （“永久移动”），302（“暂时移动”）或303（“见 其他“），如果服务器还返回一个或多个URI所在的位置 可以找到资源，然后客户端应该将新的URI视为 如果最后添加了原始URI的片段标识符。
例外情况是返回的URI已经有一个片段 标识符。在这种情况下，原始片段标识符绝不可以 没有添加到它。
因此原始URI的片段也应该用于重定向URI，除非它还包含片段。
虽然这只是2000年到期的草案，但似乎上述行为是当今网络浏览器中事实上的标准行为。
@Julian Reschke或@Mark Nottingham可能对此有更多/更好的了解。
答案 2 :(得分：2)
根据我的发现，似乎不清楚确切的行为应该是什么。很多人都有这方面的问题，有些人想通过重定向来保留书签，其中一些人想要摆脱它。
不同的浏览器以不同的方式处理这种情况，因此在实践中依赖这两种行为都没有用。
这绝对是一个浏览器问题。浏览器永远不会将URL的书签部分发送到服务器，因此服务器无法确定是否存在书签，也无法对其进行可靠的处理。