Is there a way to configure the ACO parameters ProxyHeaders* to accept the value 'Cache-control: no-cache="set-cookie, set-cookie2"'?
There does not appear to be an obvious way to delimit either the quotes or equals sign in the no-cache sub fields.
I think that's not the right way of doing it.
Try using multi valued option.
Additionally, if you are using IIS webserver, what you are trying to achieve can also be performed by setting following ACO parameter :
IIS web servers use output caching to store their responses. Responses to agents contain cookies. If the IIS web server sends an authentication response from its output cache, a different user could receive the authentication cookie in the cached response.
For example, user one authenticates successfully and the IIS server caches the response with the cookie. If user two accesses the same resource as user one, the IIS web server could possibly return the response for user one to user two.
The product disables the IIS output cache for items containing cookies by default. To revert to the behavior of the previous versions of the product for backward compatibility, change the value of the following parameter to no:
Specifies if the IIS web server stores responses containing cookies in an output cache. The IIS web server sends cached responses before CA Single Sign-On processing occurs. Disabling the output cache forces IIS to authenticate and authorize each transaction. Setting the value of the parameter to yes prevents one user from accidentally receiving authentication or authorization responses that are meant for another user.
Default: Yes (cache disabled)
Reference : https://docops.ca.com/ca-single-sign-on-12-52-sp1/en/configuring/web-agent-configuration/advanced-configuration-settings…
Appreciate the suggestion, as that does appear to have better results. The reason for the original attempt was to closely mimic how a WebSphere application was already setting the Cache-control header, but this will probably work as well.
As an FYI for the other readers, the setting was in an effort to address non-R12.52 agents, Apache agents, and misconfigured caching proxies. The IISCacheDisable, I believe, solves the issue for R12.52 IIS agents, but those other vectors still needed closing.