Also, why is redbean.dev not ported to 2.0?
Also, in Chrome, if and only if you have the dev tools open, right clicking the reload button will give you a menu with the options "Normal Reload", "Hard Reload", and "Empty Cache and Hard Reload". The third option will ensure that requests initiated by JS or that otherwise weren't part of the page load also won't be served from cache.
I'm pretty sure I remember using it earlier than that but can't be 100%.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=46845#c7
[2] http://www.bu.edu/uis_web3270/en/doc/troubleshoot/pd_ck_down...
But it hasn't always been easy to find documentation about it, thanks to a combination I think of "simplifying" everything and Google not delivering correct results since somewhere around 2010.
Thankfully now there is Kagi that actually makes a bug report if you provide them with an example that doesn't work.
Sorry for the misinformation
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ca...
Personally I've opted for "stale only" caching, so everything is served with Cache-Control: max-age=0,must-revalidate and a Last-Modified header and the browser will always make corresponding If-Modified-Since requests. This means significantly more requests per page, even if the responses are mostly 304 Not Modified, but getting to avoid all forms of cache busting makes developing a lot nicer.
How expensive is that? I would naively have expected that comparing timestamps and sending a 304 was cheap to execute.
However if you are serving clients with highly restricted bandwidth you're probably going to want extremely cacheable resources (public, immutable) and perhaps even a completely different site architecture.