- Clarity PPM typically operates in a controlled environment where the header generation is handled by a specific layer.
- In a standard out-of-the-box (OOTB) Clarity installation, the Tomcat application server manages session-related headers, while a Web Server (like Apache or Nginx) or a Load Balancer (F5/Citrix) handles static content.
- If the "multiple headers" are actually identical (e.g., two no-cache directives coming from both the App Server and the Proxy), most modern browsers (Chrome/Edge/Firefox) used in corporate environments will simply collapse them into one. Unlike the public internet, you aren't dealing with thousands of obscure mobile browsers that might fail.
- Clarity PPM is a data-heavy CRUD (Create, Read, Update, Delete) application.
- The "No-Cache" Standard: Clarity default configuration for dynamic pages (like Project lists or Timesheets) often sends Cache-Control: no-cache, no-store, must-revalidate
- If the app scan is flagging that no-cache is appearing twice, it doesn't actually cause a conflict because the directives are complementary, not contradictory. A "conflict" only matters if one header says max-age=3600 and the other says no-store. In Clarity, the goal is almost always "do not cache," so even multiple headers usually point to the same outcome
Conclusion: While consolidating into a single Cache-Control header is a standard web best practice, it is not applicable for Clarity PPM. The application architecture ensures that directives are aligned toward 'no-cache' for data integrity. Given that our supported browser matrix is limited to modern, standards-compliant browsers, the risk of directive misinterpretation is negligible.