URL 哈希在重定向之间持续存在 [英] URL hash is persisting between redirects

问题描述

出于某种原因，当发送服务器端重定向(使用 Location 标头)时，非 IE 浏览器似乎会保留 URL 哈希(如果存在).示例:

For some reason, non IE browsers seem to persist a URL hash (if present) when a server-side redirect is sent (using the Location header). Example:

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

如果我访问:

Test.aspx#foo

在 Firefox/Chrome 中，我被带到:

In Firefox/Chrome, I'm taken to:

http://www.yahoo.com#foo

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

Can anyone explain why this happens? I've tried this with various server side redirects in different platforms as well (all resulting in the Location header, though) and this always seems to happen. I don't see it anywhere in the HTTP spec, but it really seems to be a problem with the browsers themselves. The URL hash (as expected) is never sent to the server, so the server redirect isn't polluted by it, the browsers are just persisting it for some reason.

有什么想法吗?

推荐答案

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

I suggest that this is the correct behaviour. The 302 and 307 status codes indicate that the resource is to be found elsewhere. #bookmark is a location within the resource.

一旦资源(html 文档)被定位，浏览器就可以在文档中定位#bookmark.

Once the resource (html document) has been located it is for the browser to locate the #bookmark within the document.

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

The analogy is this: You want to look something up in a book in chapter 57, so you go to the library to get the book. But there is a note on the shelf saying the book has moved, it is now in the other building. So you go to the new location. You still want chapter 57 - it is irrelevant where you got the book.

这篇关于URL 哈希在重定向之间持续存在的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！