How to change the Cache-Control header?
search cancel

How to change the Cache-Control header?


Article ID: 215441


Updated On:


CA Performance Management - Usage and Administration DX NetOps


I know that we are able to send custom headers with the front end and setting them using the Ssoconfig tool.  However, I tried to set the Cache-Control: no-store in the custom header but it doesn't get set.  When I log in the Cache-Control is:

Cache-Control: private, no-store, no-cache, must-revalidate

Our security group wants it to be:

Cache-Control: private, no-store

Where would this get set (if possible) and what impact will it have on the server if the end user's browser is not caching anything.


DX NetOps Performance Management


20.2.9/10 is limited in what pages we are setting Custom Headers for.  We are only be setting the one for iframe disablement in SSO JSPs.


Upgrade to NetOps 21.2.1 whenever it's released.  It will come with a default set of custom headers OOTB and apply to more pages.

The new feature and how to manage it is documented on the r21.2 Manage Custom HTTP Headers page.

NOTE: will require upgrading PM/Spectrum/NFA/VNA all within the same maint window as they are changes in the products requiring AUTH where there used to not be.

Additional Information

21.2.1 is different, we've made serious changes to make sure most JSPs and other pages use Custom Header values.  We now will send those to DA and DA will be setting them also.

What custom HTTP Header options are supported to change?

  • For all the custom HTTP Header config options possible, there are three that are hard coded and not customizable.
    • Cache-Control:
    • Pragma:
    • Expires:
  • All other standard custom HTTP Header options Apache web servers support are acceptable to set in the Custom Headers config via SsoConfig.
    • This page is a good example of the various options.
    • Each option name is a link to a new page that details how that particular option works and what acceptable values for it are.

Engineering reviewed the locations in code where we're using those as hard coded values.

  • Cache-Control is set to:
    • In we define "Cache-Control:" as:
      • private, no-store, no-cache, must-revalidate
    • Anything calling applyStandardHeadersTo() will add the Cache-Control header above.
    • That covers (might be others, full list isn't available) desktop/page and view/page, or desktop/pagedata and view/pagedata only.
    • The other place its used is from It sets "Cache-Control:" as:
      • no-cache
    • It only does that when it finds an SsoToken in a URL and needs to resend it as a Cookie.
    • Note: At this time any image/css/etc don't provide a Cache-Control header.
  • All uses of "Expires:" set it to 0.

To allow a change to those hard coded values would be an Enhancement Request.

The default value we set OOTB for Custom.Headers is what we highly suggest to pass security scans. The default value is visible via the SsoConfig tool (1.DX NetOps->3.Performance Center->Value seen for "Custom HTTP headers to be added to our responses:". A r21.2.6 lab shows this as the OOTB value.

  • Custom HTTP headers to be added to our responses: Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; connect-src 'self'; img-src 'self' data:; style-src 'self' 'unsafe-inline'; base-uri 'self'; frame-ancestors 'self'; font-src 'self'; frame-src 'self'|X-Frame-Options: SAMEORIGIN|X-Content-Type-Options: nosniff|X-XSS-Protection: 1; mode=block|Referrer-Policy: strict-origin|Feature-Policy: 'none'|Strict-Transport-Security: max-age=63072000; includeSubDomains; preload