我正在使用GWT开发一个Web应用程序,即使Web服务器发送了该文件的新副本,我也看到了在浏览器中缓存app.nocache.js
文件的疯狂问题!
我正在使用Eclipse来编译应用程序,该应用程序在开发模式下运行。为了测试生产模式,我有一台虚拟机(Oracle VirtualBox),在我的主机(Windows 7)上运行Ubuntu客户操作系统。我在VM中运行lighttpd Web服务器。 VM正在共享我的项目的war目录,并且Web服务器正在为此目录提供服务。
我使用Chrome作为浏览器,但在Firefox中也是如此。
以下是该方案:
6E89D5C912DD8F3F806083C8AA626B83.cache.html
,但不存在(404 not found
)。app.nocache.js
WAS RELOADED 来自Web服务器(200 OK),因为服务器上的文件比浏览器缓存更新。我验证了服务器返回的新文件的文件大小和时间戳是正确的。 (这是Chrome报告服务器的HTTP响应的信息)但是,如果我在浏览器上打开app.nocache.js
,则javascript指的是6E89D5C912DD8F3F806083C8AA626B83.cache.html
!也就是说,即使Web服务器发送了新的app.nocache.js
,浏览器似乎也忽略了它并继续使用其缓存副本!
在Eclipse中转到Google-> GWT Compile。重新编译整个事情。
app.nocache.js
是否被覆盖并且有新的时间戳。app.nocache.js
发送了200 OK响应。6E89D5C912DD8F3F806083C8AA626B83.cache.html
并失败。浏览器仍在使用app.nocache.js
。6E89D5C912DD8F3F806083C8AA626B83.cache.html
(通过find和grep)出了什么问题?为什么即使服务器向其发送新副本,浏览器也会缓存此nocache.js
文件?
以下是在浏览器中单击重新加载时HTTP请求/响应标头的副本。在此跟踪中,自上次GET以来尚未重新编译服务器内容(但请注意,nocache.js的缓存版本仍然是错误的!):
Request URL:http://192.168.2.4/xbts_ui/xbts_ui.nocache.js
Request Method:GET
Status Code:304 Not Modified
Request Headersview source
Accept:*/*
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Host:192.168.2.4
If-Modified-Since:Thu, 25 Oct 2012 17:55:26 GMT
If-None-Match:"2881105249"
Referer:http://192.168.2.4/XBTS_ui.html
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94 Safari/537.4
Response Headersview source
Accept-Ranges:bytes
Content-Type:text/javascript
Date:Thu, 25 Oct 2012 20:27:55 GMT
ETag:"2881105249"
Last-Modified:Thu, 25 Oct 2012 17:55:26 GMT
Server:lighttpd/1.4.31
答案 0 :(得分:5)
避免浏览器缓存的最佳方法是设置到现在的到期时间并添加max-age = 0和必须重新验证的控件。
这是我与apache-httpd
一起使用的配置ExpiresActive on
<LocationMatch "nocache">
ExpiresDefault "now"
Header set Cache-Control "public, max-age=0, must-revalidate"
</LocationMatch>
<LocationMatch "\.cache\.">
ExpiresDefault "now plus 1 year"
</LocationMatch>
lighthttpd的配置应为
server.modules = (
"mod_expire",
"mod_setenv",
)
...
$HTTP["url"] =~ "\.nocache\." {
setenv.add-response-header = ( "Cache-Control" => "public, max-age=0, must-revalidate" )
expire.url = ( "" => "access plus 0 days" )
}
$HTTP["url"] =~ "\.cache\." {
expire.url = ( "" => "access plus 1 years" )
}
答案 1 :(得分:5)
我们遇到了类似的问题。我们发现nocache.js的时间戳没有用gwt编译更新,所以不得不在构建时触摸该文件。然后我们也应用了@ManoloCarrascoMoñino的修复程序。我写了一篇关于这个问题的博客。 http://programtalk.com/java/gwt-nocachejs-cached-by-browser/
我们正在使用GWT的2.7版本,评论也指出。
答案 2 :(得分:3)
有两个直接的解决方案(第二个是第一个的修改版本)
1)将您的* .html文件重命名为* .nocache.js,即MyProject.html为MyProject.jsp 现在在MyProject.html
中搜索你* .nocache.js脚本的位置<script language="javascript" src="MyProject/MyProject.nocache.js"></script>
添加动态变量作为JS文件的参数,这将确保每次都从服务器返回实际内容。以下是示例
<script language="javascript" src="MyProject/MyProject.nocache.jsp?dummyParam=<%= "" + new java.util.Date().getTime() %>"></script>
说明:dummyParam是没用的但是会得到我们预期的结果,即将返回200代码而不是304
注意:如果您将使用此技术,则需要确保指向正确的jsp文件以加载应用程序(在此更改之前,您使用HTML文件加载应用程序)。
2)如果您不想使用JSP解决方案并希望坚持使用您的html文件,那么在加载nocache文件时,您将需要java脚本在客户端动态添加唯一参数值。鉴于上述解决方案,我认为现在对你来说不应该是一个大问题。
我已经成功使用了第一种技术,希望这会有所帮助。
答案 3 :(得分:2)
- 浏览器上的app.nocache.js已从Web服务器重新加载(200 OK),因为服务器上的文件比浏览器缓存更新。我验证了服务器返回的新文件的文件大小和时间戳是正确的。 (这是Chrome报告服务器的HTTP响应的信息)
我不会依赖于此。我在Chrome的开发工具中看到了一些奇怪的行为,网络标签结合缓存(至少,它对我来说不是100%透明)。如有疑问,我通常还会咨询Firebug。
所以Chrome可能仍然使用旧版本。很久以前它可能已经决定,它永远不会再次重新加载资源。清除缓存应解决此问题。然后确保在重新加载页面之前设置正确的缓存标题,请参阅例如Ideal HTTP cache control headers for different types of resources
答案 4 :(得分:0)
以认知模式打开页面,以解决缓存问题并解除阻止。
您需要像其他评论中提到的那样配置缓存时间。
答案 5 :(得分:-1)
在通过Apache阻止缓存失败后,我创建了一个bash脚本,root用户在我的Linux Tomcat服务器上的cron作业中每分钟运行一次。
#!/bin/bash
#
# Touches GWT nocache.js files in the Tomcat web app directory to prevent caching.
# Execute this script every minute in a root cron job.
#
cd /var/lib/tomcat7/webapps
find . -name '*nocache.js' | while read file; do
logger "Touching file '$file'"
touch "$file"
done