Hi, @slightlyoff. With our current cache invalidation strategies, I don’t believe that adding this header would change the current behavior.
We will always force the browser to revalidate the local content and return a 304 instead of a 200 if the
If-None-Match header matches. If the browser has the local file, I do believe it is shown in the interim.
cache-control setting wouldn’t affect our CDN and, I think for the reasons above, it would also not affect the local browser cache.
I can also enter the feature request with the additional requirement of also adding a larger
max-age setting with the
stale-while-revalidate setting. This would still be in conflict with the current caching philosophy, though, and would change site behavior. It is vanishingly rare for us to change how existing sites behave and we tend to only do so if there is a urgent reason for the change.
On the other hand, the feature request for full custom header support with Large Media allows each site owner to decide what is best for them and only be changed if a site owner intentionally created header rule to change their site. On other words, full custom header support doesn’t force any existing sites to change.
Again, I’m happy to enter the feature request if you want me to do so. I just wanted to explain the reasons why I think it is actually less likely to happen than full custom header support for Large Media before proceeding.
Should I still file the feature request for the
stale-while-revalidate setting? If so, what
stale-while-revalidate settings would best meet your requirements?