views:

682

answers:

1

No matter what I do:

<meta http-equiv="Cache-Control" content="no-cache" />
<meta http-equiv="Expires" content="Fri, 30 Apr 2010 11:12:01 GMT" />
<meta http-equiv="Expires" content="0" />
<HTTP-EQUIV="PRAGMA" CONTENT="NO-STORE" />

Google Chrome does not reload any page according to the page's internal cache policy if the page is displayed in a frame. It is as though the meta tags are not even there. Google Chrome seems to be ignoring these tags.

Since I've gotten answers to this question on other forums where the person responding has ignored the operative condition, I will repeat it: this behavior occurs when the page is displayed in a frame.

I was using the latest released version and have since upgraded to 5.0.375.29 beta but the behavior is the same in both versions.

Would someone please care to confirm one way or another the behavior you are seeing with framesets and the caching/expiration policies given in meta tags?

Thanks

+1  A: 

Did you try those meta tags in both the framed document as well as the parent/hosting document?

Chris
Yes, expiration policy is in framset doc and in the content docs too. The document with the frameset declaration <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd"> does get reloaded. Chrome audit remarks that the frameset page is "explicitly non-cacheable. Consider making [it] cacheable if possible". The content docs never get reloaded. The first time I loaded them in Chrome they did not have meta tags controlling their expiration. Even though I have since added these tags and re-uploaded, Chrome seems to have cached them in perpetuity.
Tim
I see. The only way I can think to address this is perhaps an unappealing one: to specify an argument on your frame SRC to break the cache: iframe src="document.html?x=new". Or, if you have the luxury of using server-side script such as asp.net ?t=<%=DateTime.Now.Ticks%> The document would ignore the argument, but chrome would see it as a different URL. But I realize for a number of reasons this is unappealing.
Chris
Thanks. I went back and hard-coded an argument to force a reload. Even though the argument won't change because it's hard-coded, Chrome is now honoring the policy in the meta tags. So apparently the undesirable behavior is this: if the page had no cache/expiration policy the first time it was loaded, Chrome will continue to cache it even if such a policy is later added to the page. Either Chrome doesn't look for a policy if the page had none to begin with, or the NULL or UNDEFINED original expiration date is messing up the comparison with the new expiration date in some way.
Tim
It would have to fetch the file from the server to see your new meta tags, which would defeat the concept of caching, right? Seems like there is no other way than the way it is working now?
Chris
Moreover, this problem may only affect documents first loaded into Chrome quite a while ago; perhaps the lack of an expiration date is now being stored differently than it used to be. Tests with documents created today show that Chrome is honoring the meta tags.
Tim
But Audit warns that a page lacking an explicit cache policy may NOT be cached, rather than perpetually cached.
Tim
Ah, I see. If my answer helped you and you don't anticipate getting more responses I would appreciate it if you would mark this as an answer. :)
Chris

related questions