曾经用struts的多语言功能写了一些东西,用的是locale这个对象(怎么做的就不讲了,这里不是想讲struts)。
在本地测试没有问题,中文英文切换都OK。放到远程服务器上自己试了也觉得ok。但之后不断有人反映,有时候会很怪异的在英文的页面环境下点击链接后,居然又回到了中文的页面环境!我第一个反应肯定觉得是cache的问题。然后仔细检查了一次所有jsp页面的html <meta> tag,确保了所有的no cache和expire属性都设好了。然后要求大家都把IE的检查属性设置到“每次检查”。在自己机子上点击了无数遍,中文英文反复切换,似乎没有问题了。但没多久又有人投诉问题又出现了。
这里要介绍一个工具叫做httpwatch,是一个IE嵌入式的工具,用来检测IE的所有HTTP通讯的。没有了这个工具,我很难找到问题所在(当然可能有大牛一早知道,但谁都要经历不知道到知道的过程)。
jsp页面是通过例如以下的link来调用struts action切换语言环境的,http://localhost/xxx/langAction.do?lang='zh'。但发现这条link被IE缓存了,也就是说很多时候服务器根本就没有收到这个request。解决的办法可以是在link后面加上一个random number或者timestamp,问题是很多这样的link是hardcode到了flash里面(修改flash的代码? ),所以这种办法行不通。有趣的是,如果这个action仅仅是修改了session里面的locale属性,而不通知front controller 去返回结果页面给用户的话(也就是 return null),这个是肯定会cache的。然而如果要返回一个页面给用户,这个cache的频度会小很多。
最后推断,问题出在了两处地方。
1. IE的cache 也许是用url link + page result 来存储和判断是否应该使用cache,而不是真正发出request。在return null的那种情况,判断的依据是url link + null。
2。在jsp页面中,光是使用html的<meta> tag是无法禁止缓存的。一定要加上
response.setHeader("Pragma","No-cache");
response.setHeader("Cache-Control","no-cache");
response.setDateHeader("Expires", 0);
有人肯定会说,这个跟html的tag设置没有不同啊。的确,我也觉得,但实践证明,没有这几句,光靠html tag不行。
所以当action会返回页面时,有以下这两种情况:
a,返回的页面没有写上上面的禁止cache的语句(或者只写了html tag)。IE存储的是URL link + page result(cache eabled)。这也就是导致了之前为什么还会有cache的原因
b,返回的页面写上了禁止cache语句 。IE存储的是URL link + page result(cache disabled)。这样才能够实现到我们想要的目的。每次都会真正的发出request。
PS:IE的检查设置一点都信不过,尽管调到最高级别,如果没有上述措施,一样会cache。而且,你总不能告诉全世界的用户为了看你的网站去修改一下IE吧。(其他浏览器没有试验过)
在本地测试没有问题,中文英文切换都OK。放到远程服务器上自己试了也觉得ok。但之后不断有人反映,有时候会很怪异的在英文的页面环境下点击链接后,居然又回到了中文的页面环境!我第一个反应肯定觉得是cache的问题。然后仔细检查了一次所有jsp页面的html <meta> tag,确保了所有的no cache和expire属性都设好了。然后要求大家都把IE的检查属性设置到“每次检查”。在自己机子上点击了无数遍,中文英文反复切换,似乎没有问题了。但没多久又有人投诉问题又出现了。
这里要介绍一个工具叫做httpwatch,是一个IE嵌入式的工具,用来检测IE的所有HTTP通讯的。没有了这个工具,我很难找到问题所在(当然可能有大牛一早知道,但谁都要经历不知道到知道的过程)。
jsp页面是通过例如以下的link来调用struts action切换语言环境的,http://localhost/xxx/langAction.do?lang='zh'。但发现这条link被IE缓存了,也就是说很多时候服务器根本就没有收到这个request。解决的办法可以是在link后面加上一个random number或者timestamp,问题是很多这样的link是hardcode到了flash里面(修改flash的代码? ),所以这种办法行不通。有趣的是,如果这个action仅仅是修改了session里面的locale属性,而不通知front controller 去返回结果页面给用户的话(也就是 return null),这个是肯定会cache的。然而如果要返回一个页面给用户,这个cache的频度会小很多。
最后推断,问题出在了两处地方。
1. IE的cache 也许是用url link + page result 来存储和判断是否应该使用cache,而不是真正发出request。在return null的那种情况,判断的依据是url link + null。
2。在jsp页面中,光是使用html的<meta> tag是无法禁止缓存的。一定要加上
response.setHeader("Pragma","No-cache");
response.setHeader("Cache-Control","no-cache");
response.setDateHeader("Expires", 0);
有人肯定会说,这个跟html的tag设置没有不同啊。的确,我也觉得,但实践证明,没有这几句,光靠html tag不行。
所以当action会返回页面时,有以下这两种情况:
a,返回的页面没有写上上面的禁止cache的语句(或者只写了html tag)。IE存储的是URL link + page result(cache eabled)。这也就是导致了之前为什么还会有cache的原因
b,返回的页面写上了禁止cache语句 。IE存储的是URL link + page result(cache disabled)。这样才能够实现到我们想要的目的。每次都会真正的发出request。
PS:IE的检查设置一点都信不过,尽管调到最高级别,如果没有上述措施,一样会cache。而且,你总不能告诉全世界的用户为了看你的网站去修改一下IE吧。(其他浏览器没有试验过)
标签:
IE,cache,缓存
免责声明:本站文章均来自网站采集或用户投稿,网站不提供任何软件下载或自行开发的软件!
如有用户或公司发现本站内容信息存在侵权行为,请邮件告知! 858582#qq.com
桃源资源网 Design By www.nqtax.com
暂无“IE cache缓存 所带来的问题收藏”评论...