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。
任何后续时间: