On Wed, Jan 25, 2012 at 1:28 PM, John Arthorne
<John_Arthorne@xxxxxxxxxx> wrote:
Thanks for narrowing this down and finding
the webkit bug pointer John. We had come to a similar conclusion about
Ctrl+Shift+R ignoring dynamic content in the past, and found that cache
control headers fixed the problem for us. I wasn't sure if this was a bug
in Chrome, or just a case where Chrome decides that cache control headers
trump user reload requests (I know you asked for a refresh, but we know
better so we'll keep taking it from cache). We avoided this problem by
setting "Cache-Control: no-cache" on just about all dynamic content
coming from the Orion server. In this particular case the problem is that
we are caching plugin metadata in local storage, and we never even do an
xhr request to the server. Presumably Ctrl+Shift+R does not clear localStorage
so it doesn't help here. In some of our other localStorage we use our own
internal timestamp to expire our local cache and refetch from server periodically.
This internal cache expiry was just plain missing for plugin metadata.
Simon tracked this down yesterday but we neglected to update any bug. I
have updated this bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=366739
I believe the problem in 366739 is different from the one I am describing. I added a bug with repo steps:
Bug 369754 - JS files served to XHR fail when you update the server, because they are cached
Another solution that would be more fun to implement is to use 'appcache'. Maybe we could have a solution like this:
add manifest=<writable orion task-manifest + version url> to the html files
First time load, 404, ok no appcache used.
In the require() call back on each task page, build the appcache manifest based on the script tags in the page.
Add a # line to the manifest listing the manifest URL (so it marks the file with a version).
PUT the list to Orion.
Next load caches
To cause clients to update when the server updates, the only change one needs is the version number in the manifest line in the html.
Even this could be avoided if the server had a REST call giving the filesystem timestamp of the html file.
jjb
