为什么Firefox忽略基于范围的查询的缓存控制？ [英] Why is Firefox ignoring cache control on Range-based queries?

问题描述

Web服务器能够将媒体（在此示例中为音频）流式传输到浏览器。浏览器使用HTML5控件来播放媒体。然而，我发现Firefox正在缓存媒体，即使我（相信我）明确告诉它不要。我有一种预感，它与206 Partial Content响应有关，因为常规的非范围GET具有完整的200 OK响应不会被缓存。 Chrome（27）处理此问题，但Firefox（21）不会：

Web servers have the ability to stream media (audio in this example) to browsers. Browsers use HTML5 controls to play the media. What I'm discovering, however, is that Firefox is caching the media, even though I (believe I) explicitly tell it not to. I have a hunch that it has something to do with the 206 Partial Content response as a regular "non-range" GET with a full 200 OK response does not get cached. Chrome (27) handles this OK, but Firefox (21) does not:

HTTP/1.1 206 Partial Content
Date: Tue, 21 May 2013 17:24:29 GMT
Expires: 0
Pragma: no-cache
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Content-Disposition: attachment; filename="audio.wav"
Content-Type: audio/x-wav
Connection: close
Accept-Ranges: bytes
Content-Range: bytes 0-218923/218924

任何人都知道如何让Firefox不缓存这个？当我点击播放其他名称相同的音频文件时，Firefox只会播放第一个在会话中单击（缓存）的文件，而不是从服务器重新获取新文件。

Anyone got any ideas as to how to make Firefox not cache this? When I click to play other audio files that are named the same, Firefox simply plays the first one that was clicked (cached) in a session as opposed to re-fetching the new one from the server.

请注意问题似乎直接询问/回答这个问题，但它不起作用......我使用了提到的标题。

Note that this question seems to directly ask/answer this, but it does not work... I use the headers mentioned.

感谢您的帮助。

编辑：我还尝试添加ETag：标头，但Firefox仍会缓存原始响应。

EDIT: I also tried adding an ETag: header, but still Firefox caches the original response.

编辑：包含 Content-Length：标头（在此示例中为218924）似乎不会影响此问题。

EDIT: Including a Content-Length: header to match (218924 in this example) does not seem to impact the issue.

编辑：我在bugzilla.mozilla.org上提交了一个错误，但此时没有任何活动。

EDIT: I have filed a bug at bugzilla.mozilla.org but no activity on it at this point.

推荐答案

您的Firefox正在实施 rfc2616 。所以这种行为没问题。

Your Firefox is implementing Section 13.8 of rfc2616. So this behavior is alright.

13.8错误或不完整的响应缓存行为

接收不完整响应的缓存（例如，使用比Content-Length标头中指定的数据少
字节的数据）可以存储
响应。但是，缓存必须将其视为部分响应。
部分答复可按第13.5.4节所述进行组合;
结果可能是完整响应，也可能仍然是部分响应。缓存
不得使用206（部分内容）状态代码，在没有明确
标记的情况下向客户端返回部分响应。
缓存不得使用200
（OK）的状态代码返回部分响应。

13.8 Errors or Incomplete Response Cache Behavior

A cache that receives an incomplete response (for example, with fewer bytes of data than specified in a Content-Length header) MAY store the response. However, the cache MUST treat this as a partial response. Partial responses MAY be combined as described in section 13.5.4; the result might be a full response or might still be partial. A cache MUST NOT return a partial response to a client without explicitly marking it as such, using the 206 (Partial Content) status code. A cache MUST NOT return a partial response using a status code of 200 (OK).

Partial可以（或可以不）存储响应。所以Chrome和Firefox都遵循这些规则。

Partial responses may(or maynot) be stored. So Chrome and Firefox both follow the rules.

这篇关于为什么Firefox忽略基于范围的查询的缓存控制？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！