Michael, that is not an effective solution to the bfcache "problem", since when the bfcache is used the page and none of its resources will be loaded - they are already loaded and active. From the perspective of the running page, it was hidden, and then shown again, but is still in memory and won't even hit your onModuleLoad when restored in this way. To effectively handle the case where the page is now out of date, listen for the pageshow event, compare the currently running state with the server, and use that to decide if you need to reload from scratch.
https://developer.mozilla.org/en-US/docs/Glossary/bfcache
https://developer.mozilla.org/en-US/docs/Web/API/Window/pageshow_event
If you're going to specify the date in the URL, you could just as easily inline the script's contents and avoid another call - even on h2 connections, that still costs a round-trip to the server and pauses page load while waiting for that ~2k document. With that said, I largely agree with "just set good headers on the server" for your *.nocache.* documents.
Take a little care with testing/validating etag though - stock Jetty at least does not hash the file to produce this (to avoid the expense of reading the entire file to produce the hash, then re-reading it from start to stream it), but uses the file modification date assuming is a valid proxy for changes. Thwarting this, gradle helpfully sets file metadata in a jar/war to a point decades in the past, regardless of actual values, to ensure its own caching isn't impacted by files being refreshed.
On Sunday, January 5, 2025 at 6:59:32 PM UTC-6 Michael Joyner wrote:
Have looked into to using the
?datehack to prevent caching?You effectively append the system epoch time to the URL for the nocache JS file in the main HTML file.
On 1/5/25 18:03, Craig Mitchell wrote:
I'm too scared to change it without someone telling me it 100% works. 😆 When I swapped from GAE legacy to GAE standard, my filter got messed up, and people didn't get the updates correctly. The amount of times I had to ask people to clear their cache was painful.
If we can agree on what the best filter should be, we should include it in https://github.com/NaluKit/gwt-maven-springboot-archetype 🙂
On Sunday, 5 January 2025 at 6:12:52 am UTC+11 Thomas Broyer wrote:
On Friday, January 3, 2025 at 6:51:34 AM UTC+1 leon.p...@gmail.com wrote:
Hi Craig,
there are 101 hacks to try and keep the browser from caching.Problem is that it's a browser implementation on what to cache and what not, and how the browser determines what to cache when seems subject to change.So for me I prefer to assume it doesn't work.
That's not my experience.Note that refreshing a page is different from navigating to it (through a link), or going back to it from the navigation history (might also use bfcache), particularly when it comes to subresources.Having said that; except for the last-modified flag my config is the same as yours. I'll add it - thanks!If it works, it works.
Fwiw,
- "Pragma: no-cache" never had a specified behavior in responses (it was initially created for requests)
- Cache-Control is widespread (released in all browsers 11 years ago: https://caniuse.com/mdn-http_headers_cache-control) so you can replace Expires with a max-age directive.
- I would also use no-cache over no-store: the content of the nocache files don't contain any user-sensitive information so it's ok to store them as long as you revalidate with the server that they're still up-to-date. For that, you need Last-Modified or ETag (preferred) response headers though (you can just use the file's modification date, or derive an ETag from its content). If your server doesn't send those, then I'd look for a better implementation (or work around it by implementing it myself in a filter as suggested here)
See also https://jakearchibald.com/2016/caching-best-practices/ and https://web.dev/articles/http-cache#flowchart--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-tool...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/19ac9860-4656-4237-81bb-fb3ab622d3a8n%40googlegroups.com.
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/5003688d-62f7-4db4-bd81-6bf22ce6aafen%40googlegroups.com.
No comments:
Post a Comment