Hmm I just looked at what today's Firefox does (since I used Pale Moon's devtools when I checked this out), and apparently it doesn't request the static resource again and therefore does not let the server return a 304, even if there's no Cache-Control header. I wonder what sorcery Mozilla did to determine whether a resource is immutable and therefore safe to just rely on cache when reloading... Or maybe they just decided that they shouldn't bother to look for 304 in every resource whose initiator/cause in the devtools network tab is not "document"... I don't think this aggressive caching is smart since that just increases the likelihood of outdated resources being served when the browser should've revalidated its cache. So I say go for it regardless of what mainstream browsers think lol
u/emma I wonder if this can also be done in Postmill proper so that sysadmins don't have to manually add the header themselves in their reverse proxies?
nitori OP wrote
Reply to We should use "Cache-Control: immutable" for every file served that we're sure will never change by nitori
Hmm I just looked at what today's Firefox does (since I used Pale Moon's devtools when I checked this out), and apparently it doesn't request the static resource again and therefore does not let the server return a 304, even if there's no Cache-Control header. I wonder what sorcery Mozilla did to determine whether a resource is immutable and therefore safe to just rely on cache when reloading... Or maybe they just decided that they shouldn't bother to look for 304 in every resource whose initiator/cause in the devtools network tab is not "document"... I don't think this aggressive caching is smart since that just increases the likelihood of outdated resources being served when the browser should've revalidated its cache. So I say go for it regardless of what mainstream browsers think lol