19

RFC 似乎建议客户端应该永久缓存响应： http ://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

10.3.2 301 永久移动

请求的资源已被分配一个新的永久 URI，并且任何将来对该资源的引用都应该使用返回的 URI 之一。如果可能，具有链接编辑功能的客户端应该自动将对 Request-URI 的引用重新链接到服务器返回的一个或多个新引用。除非另有说明，否则此响应是可缓存的。

新的永久 URI 应该由响应中的 Location 字段给出。除非请求方法是 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。

    • 4

    2 回答 2

    12

    我进行了一些测试，发现一些浏览器确实缓存了 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 已缓存）。

    我测试了在地址框中输入旧地址，从书签访问旧地址，以及从页面上的链接访问旧地址。无论地址如何被访问，每个浏览器都以相同的方式工作。

    [我在调查类似的超级用户问题时发现了这个问题：浏览器是否会更改已保存书签的 URL 以响应 301 重定向？]

    于 2010-06-12T06:21:49.413 回答
    -1

    您可以使用此解决方法：为用户和仅搜索引擎进行重定向
    。在服务器端，只需检查用户代理。如果是机器人，请进行重定向。否则，做.302301301302

    这不是“黄金之路”，但效果很好

    于 2012-09-28T22:48:49.873 回答