You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
It's recommended to send long far-future client cache TTLs in HTTP response headers for static resources like images, documents, and CSS files, and this is what OC also does. However, in the Media Library admin this causes an issue if you change files, since thumbnails and "View" links will now load the old files. This is especially a problem with CDNs, since then it's not just your browser caching these files but the CDN too, which for an ordinary user is impossible to purge, and thus they won't see the updated files.
Describe the solution you'd like
Make Media Library admin thumbnails and "View' links use the usual cache-busting parameter mechanism.
Describe alternatives you've considered
The only alternative I can think of is using ETAGs but validating resources would still need an HTTP request by clients (though a small HEAD one).
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
It's recommended to send long far-future client cache TTLs in HTTP response headers for static resources like images, documents, and CSS files, and this is what OC also does. However, in the Media Library admin this causes an issue if you change files, since thumbnails and "View" links will now load the old files. This is especially a problem with CDNs, since then it's not just your browser caching these files but the CDN too, which for an ordinary user is impossible to purge, and thus they won't see the updated files.
Describe the solution you'd like
Make Media Library admin thumbnails and "View' links use the usual cache-busting parameter mechanism.
Describe alternatives you've considered
The only alternative I can think of is using ETAGs but validating resources would still need an HTTP request by clients (though a small HEAD one).
The text was updated successfully, but these errors were encountered: