3

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

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.

Thanks for any help.

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

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

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

Community
  • 1
  • 1
mark
  • 5,269
  • 2
  • 21
  • 34

1 Answers1

1

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

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 responses may(or maynot) be stored. So Chrome and Firefox both follow the rules.

Community
  • 1
  • 1
user568109
  • 47,225
  • 17
  • 99
  • 123
  • Thanks for the response. This section doesn't seem to apply to my case though; my 206 is a specific/signaled partial response not an error or incomplete response. The problem I'm seeing is Firefox is caching the entire complete resulting resource (collection of partial responses) even though they are marked as non-cacheable. – mark May 30 '13 at 12:38
  • A 206 response **is** an incomplete response as it contains "fewer bytes of data than specified in a Content-Length header". – idbehold May 30 '13 at 15:33
  • I guess this depends on how that section is interpreted. I would read it as *"the partial result may be put in the cache if the Cache-Control allows it"*, and not as *"the partial result may be cached, even if it contradicts the Cache-Control headers"*. So I'd say this is a bug in Firefox. The important part is this: "A cache that receives...". **No cache** should receive that partial response since the headers clearly forbid that. – Sergiu Dumitriu Jun 01 '13 at 18:40
  • @idbehold I've tried it both ways, with no Content-Length header and specifying Connection: close, and with the Content-Length header specifying the actual length of the response content (which might be a *part* of the complete resource but is exactly what is in the response) so it is complete from a response-perspective. – mark Jun 03 '13 at 12:36