![]() They seem to use max-age=0 or no-cache randomly depending on the resource. Google might not be a good choice for emulation, either. While they essentially run massive caching arrays as their primary business, and should be experts, they actually have a vested interest in causing more data to be downloaded from their networks. I would avoid the use of no-cache entirely, as it seems it has been bastardized by some browsers and popular caches to the functional equivalent of no-store.Īdditionally, do not emulate Akamai and Limelight. For per-user items with the same consideration, use private,max-age=0. My advice would be to set public,max-age=0 for non-sensitive resources you want to have checked for freshness on every request, but still allow the performance and bandwidth benefits of caching. ![]() Squid Cache, by default, seems to never store anything with a no-cache header, just like Firefox. Firefox 3.5, however, seems to treat no-cache as equivalent to no-store, which sucks for performance and bandwidth usage. IE8 treats no-cache responses with the same semantics as max-age=0,must-revalidate. ![]() However, they differ in their "friendliness" to the origin server. In my recent tests with IE8 and Firefox 3.5, it seems that both are RFC-compliant. "end-to-end reload") doesn't revalidate and the server MUST NOT use a cached copy when responding. On the other hand, sending a request with Cache-Control: no-cache (aka. If the reply is then 304 (Not Modified), the cached entity can be used. with the If-Not-Modified header) all the way to the origin server. "end-to-end revalidation"), then each cache along the way will revalidate its cache entry (eg. If a user agent sends a request with Cache-Control: max-age=0 (aka. You can also look at 13.2.6 Disambiguating Multiple Responses. I believe shahkalpesh's answer applies to the user agent side. So maybe that's a way to get the MUST-revalidate behavior of no-cache, while avoiding the apparent migration of no-cache to doing the same thing as no-store (ie. I came across a page, Cache Control Directives Demystified, that says (I can't vouch for its correctness):Īs an aside, it appears to me that Cache-Control: max-age=0, must-revalidate should basically mean the same thing as Cache-Control: no-cache. Maybe you'd want the SHOULD-revalidate behavior when baseball stats are generated in a page, but you'd want the MUST-revalidate behavior when you've generated the response to an e-commerce purchase.Īlthough you're correct in your comment when you say no-cache is not supposed to prevent storage, it might actually be another difference when using no-cache. In other words, caches may sometimes choose to use a stale response (although I believe they have to then add a Warning header), but no-cache says they're not allowed to use a stale response no matter what. ![]() with the If-Not-Modified header) before using a cached copy, whereas, no-cache tells them they MUST revalidate before using a cached copy. I believe max-age=0 simply tells caches (and user agents) the response is stale from the get-go and so they SHOULD revalidate the response (eg. The other side is where it can be sent by the browser (aka. One side is where it can be sent by the web server (aka. There are two sides to the Cache-Control header. I had this same question, and found some info in my searches (your question came up as one of the results).
0 Comments
Leave a Reply. |