为什么Firefox为什么忽略缓存头并重新验证应缓存的响应？

Question

我有一些不可变的图像资源，可以永久缓存。 Chrome似乎尊重我的响应标头，并且不重新验证资源：

这是Chrome中这些资源之一的示例。如您所见，我包括cache-control: public, max-age，expires，etag和last-modified，并且资源是从“内存缓存”中提供的：

---

但是，Firefox不遵守这些标头，并且会在每次加载时重新验证资源！每次页面加载时，我的服务器都被要求提供每个个人资料图片的请求，并返回304：

这是在这样的请求上导致304的示例：

我不知道为什么Firefox会忽略缓存头，并继续使用304。我已经尝试了各种与缓存相关的头，并阅读了"cacheable"的标准，但是Firefox并没有运气。

Answer 1

只是更详细些，让我详细介绍一下ETag。从技术上讲，Firefox可以正确处理它。当存在Etag时，客户端或中间缓存需要执行GET或HEAD，以确保提供的内容没有更改。

If-None-Match标头告诉服务器它具有哪个版本。如果尚未更改，则服务器/代理返回304。

您可以通过使其成为弱ETag来修改重新验证行为。这是通过在ETags值（即ETag: /W #########）前面加上W /来完成的。这可以在您的服务器上处理，或者如果您无法通过CDN上的重写规则来控制它。

Firefox可能的解决方法是添加Cache-Control Immutable选项。 Cache-Control: Immutable。如果不查看Firefox缓存试探法中的代码，我不能肯定地说，但是应该很容易测试。

如果其他服务器不支持标题，则它们将忽略它。

Etags也不适用于字节范围请求。因此，如果您没有使用它们的特定原因，请考虑将其关闭。

Answer 2

简单地说：Firefox在浏览器刷新时重新验证缓存的内容。

这曾经是所有浏览器的工作方式。一次假设如果用户正在积极刷新其页面可能是合理的，这是因为出现了问题并且需要从头开始。现在，随着显示实时内容的网站的出现，“刷新”的使用可能会大为不同。

Chrome和Firefox似乎采取不同的方式来处理此问题。 Chrome浏览器的方法是使其刷新行为更智能，更复杂，而Firefox选择了明确依赖开发人员，以指示使用Cache-Control: immutable响应标头从无需重新验证非陈旧资源。 （有关此区别的更多信息，请参见Cache-Control: immutable。）>

如果此刷新行为对于您的应用程序而言是重要的用例（而不是仅用于调试目的，则添加this answer应该可以在Firefox中解决此问题。