问处理301重定向时的客户端Web浏览器行为

EN

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以外的请求，则用户代理不能自动重定向请求，除非用户可以确认它，因为这可能会改变发出请求的条件。

注意:在收到301状态码后自动重定向POST请求时，某些现有的HTTP/1.0用户代理会错误地将其更改为GET请求。

我很难找到任何主流浏览器的具体浏览器文档，说明它们是如何处理这些问题的。

我已经开始挖掘firefox的源代码，但很快就迷失了方向。

以下情况是否适用于哪种浏览器(如果有)，是否有明确的文档说明Firefox或IE的情况？

第一次：

• 1.1:用户输入指向站点A的链接，或单击指向站点A的链接
• 1.2:浏览器第一次解释站点A的链接，没有缓存。将GET发送到站点A。
• 1.2:站点A响应301重定向到站点B
• 1.3:浏览器将GET发送到站点B。

任何后续的时间：

• 2.2:用户单击指向站点A的链接
• 2.2:浏览器看到，由于过去的301重定向，站点A现在应该是站点B。
• 2.3:在站点A没有发起任何请求的情况下，浏览器在站点B启动GET。