【发布时间】:2012-10-25 18:31:12
【问题描述】:
我正在使用 GWT 开发一个 Web 应用程序,并且在浏览器中缓存 app.nocache.js 文件时发现了一个疯狂的问题,即使 Web 服务器发送了该文件的新副本!
我正在使用 Eclipse 编译应用程序,该应用程序在开发模式下工作。为了测试生产模式,我有一个虚拟机 (Oracle VirtualBox),在我的主机 (Windows 7) 上运行 Ubuntu 来宾操作系统。我在虚拟机中运行 lighttpd 网络服务器。虚拟机正在共享我项目的 war 目录,而 Web 服务器正在为该目录提供服务。
我使用 Chrome 作为浏览器,但同样的事情发生在 Firefox 中。
这是场景:
- 应用程序的网页是空白的。根据 Chrome 的“检查元素”工具,这是因为它正在尝试获取不存在的
6E89D5C912DD8F3F806083C8AA626B83.cache.html(404 not found)。 - 我检查了war目录,果然,那个文件不存在。
- 浏览器上的
app.nocache.js已从 Web 服务器重新加载 (200 OK),因为服务器上的文件比浏览器缓存更新。我验证了服务器返回的新文件的文件大小和时间戳是正确的。 (这是 Chrome 报告的有关服务器 HTTP 响应的信息) 但是,如果我在浏览器上打开
app.nocache.js,javascript指的是6E89D5C912DD8F3F806083C8AA626B83.cache.html!!!也就是说,即使网络服务器发送了一个新的app.nocache.js,浏览器似乎也忽略了它并继续使用它的缓存副本!转到 Google->在 Eclipse 中编译 GWT。重新编译整个东西。
- 在 war 目录中验证
app.nocache.js是否已被覆盖并具有新的时间戳。 - 从 Chrome 重新加载页面并再次验证服务器是否向
app.nocache.js发送了 200 OK 响应。 - 浏览器再次尝试加载
6E89D5C912DD8F3F806083C8AA626B83.cache.html并失败。浏览器仍在使用app.nocache.js的旧缓存副本。 - 绝对确定在 war 目录中没有任何内容指向
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
【问题讨论】:
-
顺便说一句,这似乎类似于stackoverflow.com/questions/3407649/…,但它不包含任何帮助我解决此问题的信息。
-
是的,似乎正在发生正确的事情,因为该页面显示“If-Modified-Since fetch 就足够了”。我可以从 Chrome Inspect Element 工具中得知浏览器在 GET 请求中发送了“If-Modified-Since:Thu, 25 Oct 2012 17:03:53 GMT”,而服务器以“Last-Modified:Thu, 25 2012 年 10 月 17:55:26 GMT"
-
添加了 HTTP 请求/响应标头跟踪,以便潜在帮助者更清楚地了解这一点。
-
我怀疑问题在于浏览器正在猜测 nocache.js 文件的新鲜度生命周期,并确定该文件仍然是“新鲜的”。这是来自阅读 HTTP RFC 第 13.2.4 节:“如果没有任何过期,Cache-Control: max-age 或 Cache-Control: s-maxage(参见第 14.9.3 节)出现在响应中,并且响应确实不包括缓存的其他限制,缓存可以使用启发式计算新鲜生命周期。” (来自w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13)
标签: gwt browser-cache lighttpd