CSP Gateway Configuration Guide - InterSystems Documentation

CSP Gateway Operation and Configuration
This would result in every single page, for each state, being cached independently of one another for two hours:
Weather.csp
Weather.cspState=WA
Weather.cspState=TX
...etc.
Now suppose that we add further functionality to show the weather for a specific city. In order to cache pages based on the
state and city parameter, we would change the cache directives to:
%response.Expires=[2 hours time]
%response.VaryByParam="State;City"
The ASP.NET equivalent would be:
The VaryByParam property allows us to cache multiple versions of the same page based on parameters sent through HTTP
GET/POST. Be extremely careful when using *, as this can potentially fill the output cache with pages that are not frequently
accessed. Remember, the more specific we make the VaryByParam property, the more frequently the Gateway can serve
pages from the cache. For example, when only specifying a state, we have 51 versions of the page in the cache (50 states
+ the version with no parameters). When the city parameter is added, and assuming that we have an average of 15 cities
per-state, we suddenly increase the number of potentially cached pages to 751.
The Gateway automatically evicts pages from the cache if it becomes constrained by memory as a result of the total volume
of the cache becoming too large.
2.7.3 Preserving the User’s Session ID for Cached Pages
The requesting user’s session ID must be preserved within pages retrieved from the cache, regardless of whether the session
is being maintained via a Cookie (CSPSESSIONID) or via the token (Form/URL variable: CSPCHD).
When a page is cached it is cached against the identity of the user that actually retrieved the page from Caché. This page
contains the session ID as either the CSPSESSIONID cookie or as the CSPCHD token. Before serving a cached page to the
user, the Gateway replaces all occurrences of both variables with the requesting user’s session token. In fact, the session
cookie is actually removed from the cache, which achieves the same thing because the Cookie is preserved on the requesting
user’s browser.
For example, let’s suppose that a page is cached by user xxxxxxx. The page is cached with the following identity:
Set-Cookie: CSPSESSIONID=xxxxxxx;
Now, when another user aaaaaaa subsequently retrieves this page from the cache, the cookie is, theoretically, changed
to:
Set-Cookie: CSPSESSIONID=aaaaaaa;
In fact, as mentioned previously, the cookie is simply left alone on the requesting user’s browser.
The Gateway must, however, take action for pages that maintain the user’s session through the session token, CSPCHD. In
this case, the initial cached page contains references to the original user as shown below:
The Gateway automatically changes the value of the session token to reflect the identity of the requesting user. For example,
when user aaaaaaa subsequently requests this page from the cache, the Gateway modifies these lines as follows:
46 CSP Gateway Configuration Guide