Description
We currently have no way of invalidating the browser's cache for attachments that have changed (uploaded a new version with the same name). The Attachment URL stays the same, so the browser does not know when to download a new version.
We could use one for the 2 options:
- Cache buster parameter (similar to ?rev=1.6)
- HTTP standard cache control mechanism, as suggested by mflorea, to return a 304 code instead of the content and instruct the browser that the resource has not changed, in certain conditions:
Nice Guide on both options: https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching
Note that we are already using the cache buster technique for JSX and SSX resources, to force client cache invalidations whenever they are changed.
Also, the Skin action could benefit from such an improved cache control for a better response to XWiki updates or to customizations done on the server.
Attachments
Issue Links
- is related to
-
XWIKI-16388 Regression on SEO caused by XWIKI-15450
-
- Closed
-
-
-
- Closed
-
-
XWIKI-16378 /downloadrev/ with no rev should return last rev
-
- Open
-
- relates to
-
-
- Open
-
-
-
- Closed
-
-
-
- Closed
-