How to make the browser stop caching GWT nocache.js
I'm developing a web app using GWT and am seeing a crazy problem with caching of the
app.nocache.js file in the browser even though the web server sent a new copy of the file!
I am using Eclipse to compile the app, which works in dev mode. To test production mode, I have a virtual machine (Oracle VirtualBox) with a Ubuntu guest OS running on my host machine (Windows 7). I'm running lighttpd web server in the VM. The VM is sharing my project's war directory, and the web server is serving this dir.
I'm using Chrome as the browser, but the same thing happens in Firefox.
Here's the scenario:
- The web page for the app is blank. Accorind to Chrome's "Inspect Element" tool, it's because it is trying fetch
6E89D5C912DD8F3F806083C8AA626B83.cache.html, which doesn't exist (
404 not found).
- I check the war directory, and sure enough, that file doesn't exist.
app.nocache.json the browser WAS RELOADED from the web server (200 OK), because the file on the server was newer than the browser cache. I verified that file size and timestamp for the new file returned by the server were correct. (This is info Chrome reports about the server's HTTP response)
However, if I open the
6E89D5C912DD8F3F806083C8AA626B83.cache.html!!! That is, even though the web server sent a new
app.nocache.js, the browser seems to have ignored that and kept using its cached copy!
Goto Google->GWT Compile in Eclipse. Recompile the whole thing.
- Verify in the war directory that the
app.nocache.jswas overwritten and has a new timestamp.
- Reload the page from Chrome and verify once again that the server sent a 200 OK response to the
- The browser once again tries to load
6E89D5C912DD8F3F806083C8AA626B83.cache.htmland fails. The browser is still using the old cached copy of
- Made absolutely certain in the war directory that nothing is referring to
6E89D5C912DD8F3F806083C8AA626B83.cache.html(via find and grep)
What is going wrong? Why is the browser caching this
nocache.js file even when the server is sending it a new copy?
Here is a copy of the HTTP request/response headers when clicking reload in the browser. In this trace, the server content hasn't been recompiled since the last GET (but note that the cached version of nocache.js is still wrong!):