Why did Cache-Control change from 'public to 'private'?
How To articles are not official guidelines or officially supported documentation. They are community-contributed content and may not always reflect the latest updates to Liferay DXP. We welcome your feedback to improve How To articles!
While we make every effort to ensure this Knowledge Base is accurate, it may not always reflect the most recent updates or official guidelines.We appreciate your understanding and encourage you to reach out with any feedback or concerns.
Legacy Article
You are viewing an article from our legacy "FastTrack"
publication program, made available for informational purposes. Articles
in this program were published without a requirement for independent
editing or verification and are provided"as is" without
guarantee.
Before using any information from this article, independently verify its
suitability for your situation and project.
Issue
- Prior to 7.4 U84, Cache-Control was set to 'public', and after upgrading to 7.4 U84 or above (including any Quarterly Release version), Cache-Control is now set to 'private'. Due to this, CDNs may have issue caching JavaScript and CSS.
Environment
- DXP 7.4
- Quarterly Release
Resolution
- This change was implemented in LPS-188020: Fix I18N for ES modules, in order to fix how JavaScript files are served in
- The problem before that fix was that JavaScript files were being translated and set as cacheable forever (maximum
max-age possible and public). This could lead to a variety of issues like:
- JavaScript content not being updated after upgrades or new hotfix installation
- Customizations to I18N labels not being reflected unless users cleared their cache
- Proxies or intermediate servers (like CDN caching) needed to be cleared too
- Therefore our team decided to add
private and no-cache to the responses in addition to an ETag header that is honored for caching purposes (see ETag header - HTTP | MDN ).
- What that means is that even though the JavaScript requests are no longer infinitely cacheable, they are cacheable by means of the ETag mechanism, which shouldn’t have a huge impact in the systems.
- It’s true that ETag requires re-requesting cached resources to the server in case they have changed so that’s more load than before. But the content is not downloaded since the server replies with a 304 HTTP code (see 304 Not Modified - HTTP | MDN ).
- We are currently working in making DXP caching more efficient (see LPD-53360: Enforce Javascript resources to be fully cacheable ) and, among other things, we will allow time based caching in addition to ETag based caching for labels. This may make the scenario even more performant as long as users are willing to accept delays in updates of I18N labels.
Did this article resolve your issue ?