处理 301 重定向时的客户端 Web 浏览器行为
Posted
技术标签:
【中文标题】处理 301 重定向时的客户端 Web 浏览器行为【英文标题】:Client Web Browser Behavior When Handling 301 Redirect 【发布时间】:2011-02-09 14:24:22 【问题描述】:RFC 似乎建议客户端应该永久缓存响应: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
10.3.2 301 永久移动
请求的资源已被 分配了一个新的永久 URI 和任何 将来对该资源的引用 应该使用返回的 URI 之一。 具有链接编辑功能的客户端 应该自动重新链接 对 Request-URI 的引用 或更多的新参考返回 在可能的情况下由服务器。这 除非指明,否则响应是可缓存的 否则。
应该给出新的永久 URI 通过响应中的位置字段。 除非请求方法是 HEAD, 响应的实体应该 包含一个简短的超文本注释 指向新 URI 的超链接。
如果收到 301 状态码 响应 GET 以外的请求 或 HEAD,用户代理不得 自动重定向请求 除非能得到相关部门的确认 用户,因为这可能会改变 请求的条件 发布。
Note: When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request.
我很难为任何主要浏览器找到具体的浏览器文档来说明它们如何处理这些。
我已经开始深入研究 Firefox 的源代码,但很快就迷路了。
以下情况是否适用于哪些浏览器(如果有),是否有针对 Firefox 或 IE 的明确文档说明了这一点?:
第一次来:
1.1:用户输入指向站点 A 的链接,或单击指向站点 A 的链接 1.2:浏览器第一次解释站点 A 的链接,没有缓存。将 GET 发送到站点 A。 1.2:站点 A 响应 301 重定向到站点 B 1.3:浏览器向站点 B 发送 GET。任何后续时间:
2.2:用户单击指向站点 A 的链接 2.2:浏览器发现,由于过去的 301 重定向,站点 A 现在应该是站点 B。 2.3:没有在站点 A 发起任何请求,浏览器在站点 B 发起 GET。【问题讨论】:
【参考方案1】:我进行了一些测试,发现一些浏览器确实缓存了 301 结果:
缓存 301 结果并跳过将来联系旧地址? Internet Explorer 7 否 火狐 3.0 没有 铬 4.0 是 Opera 10.01 适用于 google.com,不适用于 www.rnhart.net我是如何测试的
我使用以下两个 301 结果进行测试:
google.com 向 www.google.com 返回 301 www.rnhart.net 向 rnhart.net 返回 301我在自己的计算机上启动了代理服务器(Proxomitron Naoko 4.2,所有过滤器都关闭了)。在每个浏览器中,我将代理设置设置为指向我自己的计算机。我清除了浏览器的缓存,然后多次访问旧地址并查看代理服务器的日志窗口以查看浏览器发出的请求。
第一次访问旧地址,代理日志显示旧地址请求、301响应和新地址请求。如果再次访问旧地址,日志要么显示相同的请求集(301 未缓存),要么仅显示新地址请求(301 已缓存)。
我测试了在地址框中输入旧地址,从书签访问旧地址,以及从页面上的链接访问旧地址。无论地址如何访问,每个浏览器的工作方式都相同。
[我在调查类似的超级用户问题时发现了这个问题:Do browsers change URLs of saved bookmarks in response to 301 redirection?]
【讨论】:
Bavi_H,您的测试结果与您提到的类似问题不同(您实际上对 Chrome 和 Opera 表示“否”)。你能更新你的答案吗? @Jesper Rønn-Jensen:这些问题询问的是不同的事情(如果书签地址被更改;如果与旧服务器的连接被跳过)。 感谢 Bavi_H 的澄清 :)【参考方案2】:您可以使用此解决方法:
为用户设置302
重定向,为搜索引擎设置301
。
在服务器端,只需检查用户代理。如果是机器人,请执行301
重定向。否则,请执行302
。
这不是“黄金之路”,但效果很好
【讨论】:
以上是关于处理 301 重定向时的客户端 Web 浏览器行为的主要内容,如果未能解决你的问题,请参考以下文章