出于某种原因，当发送服务器端重定向（使用 Location 标头）时，非 IE 浏览器似乎会保留 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 哈希（如预期的那样）永远不会发送到服务器，因此服务器重定向不会被它污染，浏览器只是出于某种原因将其持久化。
有任何想法吗？
我建议这是正确的行为。302 和 307 状态码表明该资源可以在别处找到。#bookmark是资源中的一个位置。
一旦资源（html 文档）被定位，浏览器就可以#bookmark在文档中定位。
类比是这样的：你想在第 57 章的书中查找一些东西，所以你去图书馆取书。但是书架上有一张纸条，上面写着这本书已经搬了，现在在另一栋楼里。所以你去新的位置。你仍然想要第 57 章——这与你从哪里得到这本书无关。
这是以前的 HTTP 规范没有涵盖的一个方面，但在后来的 HTTP 开发中已经解决：
如果服务器返回响应码为 300（“多选”）、301（“永久移动”）、302（“临时移动”）或 303（“查看其他”），并且服务器还返回一个或多个 URI如果可以找到资源，则客户端应该将新的 URI 视为在末尾添加了原始 URI 的片段标识符。
例外情况是返回的 URI 已经具有片段标识符。在这种情况下，不得不添加原始片段标识符。
因此，原始 URI 的片段也应该用于重定向 URI，除非它还包含片段。
尽管这只是 2000 年到期的草案，但上述行为似乎是当今 Web 浏览器中事实上的标准行为。
@Julian Reschke或@Mark Nottingham可能对此了解更多/更好。
根据我的发现，似乎不清楚确切的行为应该是什么。有很多人对此有疑问，他们中的一些人希望通过重定向保留书签，其中一些人希望摆脱它。
不同的浏览器对此的处理方式不同，因此在实践中依赖任何一种行为都没有用。
肯定是浏览器问题。浏览器从不将 URL 的书签部分发送到服务器，因此服务器无法确定是否存在书签，也无法可靠地对其进行处理。