Closed sippsack closed 8 years ago
Had this problem too, it vanishes when the cache is deleted. Anyways, we should handle those errors since they restrict users with an older version of the application to load the page (we can hardly inform them to manually delete their cache).
How do you delete your cache? I don't like to reset the full chrome settings. Is it possible for dev.dukecon.org only?
For me it was sufficient to just delete cookies and images/files:
On 07.12.2015, at 09:46, Falk Sippach notifications@github.com wrote:
How do you delete your cache? I don't like to reset the full chrome settings. Is it possible for dev.dukecon.org only?
— Reply to this email directly or view it on GitHub.
Gerd Aschemann --- Veröffentlichen heißt Verändern (Carmen Thomas) +49/173/3264070 -- gerd@aschemann.net -- http://www.aschemann.net
Seems that this is part of a bigger problem: Upgrading from 1.0 to 1.1 on the same url does not really work, the app is completely cached. Without clearing the cache, you won't get the new version anyway. We have to find a solution for this.
Maybe there is a chance to do some URL magic by the switch to https. Chrome seems to handle the same server/uri differently for http and https. I have prepared two URLs
(visit http first, then https!)
For me, Chrome happily (re)loads the second URL completely without taking care of the old version in the first place.
Will this be the unique chance to get rid of an old version?
@ascheman: Add some tests with more headers ...
@annam002: Enforce full cache-invalidation by "special" flag in data. Maybe we should provide an additional rest call for that? Idea: let the html5 application check a particular rest service every know and then for a "desired" version. If the local version as delivered by .../versions/dukecon_html5-version.txt does not match, enforce cache invalidation. That means, the application has to store the value from the version.txt file during load. If the server provides a newer/different version.txt, invalidate the cache. This does not even require a particular rest service in the first run. The rest service would be an optimization: Only invalidate cache if enforced by particular data as delivered by the rest service.
@annam002 / @steffchep please retest the caching problem as I see a strange behaviour in Chrome.
It can be tested the following way (only with local builds):
git checkout 127eee5b8e63a572a2b0da58013680d1551340fc; mvn clean install
(will checkout a client as of November and install it to the local Maven repository)mvn clean spring-boot:run -DskipTests
git checkout develop; mvn clean install
@ascheman I had to remove the no-store in https://github.com/dukecon/dukecon_server/commit/1de0b7a3f33240efed2ada4c99dc8b3f21129c15 as reloading of the application stopped working in firefox.
@ascheman : I don't understand: if you install an old version where the caching problem was still existing, then you will observe that the caching problem still exists???
Retested and seems to work. Unless we want to test in more browsers, this can be closed.
@annam002: Please re-test for 1.1 (see due date!)
Tested ok in the following browsers: Chrome, Firefox, Internet Explorer, Edge, Seamonkey, Chrome for Android, Firefox for Android, Safari (IOS 9.2)
http://dev.dukecon.org/latest/index.html doesn't finish loading in Chrome:
Uncaught TypeError: self.selectedDayIndex is not a function
Looks like a cache problem. It works in a new opened incognito window where local stoage is empty.
My assumption (correct me, if I'm wrong): It correlates with a mismatch between the TalkListViewModel instance loaded from offline cache and the current data model. Deleting the local storage would stop this to happen. But our users can't do this. There should be a offline cache invalidation after a new html5 client deployment.