Smarter by Design.Simpler for Business
TR7Enterprise Application Delivery & Security Platform
How do I prevent user-specific content from being cached by mistake?
Short answer
Caching Rules are kept limited to static file paths; requests that carry a session cookie, an Authorization header or personal paths such as /account are left out of the rule with the negated forms of the conditions. Ignore Response Headers and Ignore HTTP Method Standards must remain off; in this way, the cache headers of the Backend Service are taken into account and only GET and HEAD requests are cached. If personalized content is to be cached deliberately, a value that distinguishes the user (e.g. the session cookie) is added to the key with Dynamic Caching.
Problem: One User's Page Can Be Shown to Another User
If a user-specific response (account page, cart, personal API response) is cached, that response can be served to another user who requests the same address. This means both a privacy violation and incorrect content; the cache must be limited only to content that is the same for everyone.
Solution: Two Methods
| Your situation | Suitable method |
|---|---|
| Personal content must never be cached | Method 1: Narrow rule and negated conditions |
| Personalized content will be cached deliberately | Method 2: Dynamic caching |
Method 1: Narrow Rule and Negated Conditions Recommended
- How it works The rule covers only static files; requests that carry a session cookie, an
Authorizationheader or a personal path stay out with negated conditions. - Where it is openedLoad Balancer → Conditions · Load Balancer → Profiles → Cache
- Requirement Ignore Response Headers and Ignore HTTP Method Standards off (default); the Backend Service must send
Cache-Control: privateorno-storeon personal pages - vService type HTTP
Step-by-Step Configuration
1
Adım 1 Create the session cookie condition
Load Balancer → Conditions → Add; Criteria = User Cookie Name, cookie name (e.g. SESSIONID), match Is present → Add.
2
Adım 2 Create the other conditions
If needed, the Criteria = HTTP Header (Authorization, Is present) and Criteria = Path (/account, Start) conditions are created in the same way.
3
Adım 3 Open the profile
On the Load Balancer → Profiles → Cache screen, Add is used for a new profile (how to add), and right-click on the row → Edit for an existing profile.
4
Adım 4 Narrow the rule
In the Caching Rules field, the default static extension condition is kept; broad conditions that cover all paths are not added (operational best practices). The negated forms of the created conditions are added to the same group with and (Can I use a condition in negated form ("if not")?).
5
Adım 5 Check the Ignore options
It is checked that the Ignore Response Headers and Ignore HTTP Method Standards switches are off.
6
Adım 6 Save the profile
Add is clicked for a new profile, Save when editing. If the profile is already assigned to a vService, the change is applied without dropping open connections and the copies in the cache are deleted; in this way, previously stored personal copies are also cleared.
7
Adım 7 Select the profile on the vService
If a new profile was created, the profile is selected in the Load Balancer → Load Balancer vService List → vService → Edit → Details → Cache box.
8
Adım 8 Save
Save is clicked; the change is applied without dropping open connections. In a cluster, it is also sent to the peer device with the default auto-sync; if Manual Sync Mode is on, it is sent with Synchronize.
Verification
1Personal requestClient side
The same address is requested twice with the session cookie: curl -s -o /dev/null -D - -H "Cookie: SESSIONID=A" https://www.example.com/logo.png
Expected
TRCACHE: MISS in both requests2General requestClient side
The same address is requested twice without a cookie.
Expected
TRCACHE: MISS, then TRCACHE: HITMethod 2: Dynamic Caching
- How it works A value that distinguishes the user, such as the session cookie, is added to the cache key; each user gets their own copy.
- Where it is openedLoad Balancer → Profiles → Cache → Dynamic Caching
- Requirement The personal content must be suitable for being served again only to the same user; as many copies as the number of users are kept in memory
- vService type HTTP
Step-by-Step Configuration
1
Adım 1 Open the profile
On the Load Balancer → Profiles → Cache screen, Add is used for a new profile, and right-click on the row → Edit for an existing profile.
2
Adım 2 Turn on Dynamic caching
The Dynamic Caching switch is turned on; the Key list appears.
3
Adım 3 Add the session cookie to the key
The Request Cookie Content Smart Variable is added to the Key list with the name of the session cookie (e.g. SESSIONID) (What is Dynamic Caching, and when should it be used?).
4
Adım 4 Save the profile
Add is clicked for a new profile, Save when editing. If the profile is already assigned to a vService, the change is applied without dropping open connections.
5
Adım 5 Select the profile on the vService
If a new profile was created, the vService is opened with Edit and the profile is selected in the Details → Cache box.
6
Adım 6 Save
Save is clicked. In a cluster, it is also sent to the peer device with the default auto-sync; if Manual Sync Mode is on, it is sent with Synchronize.
Verification
1DistinctionClient side
The same address is requested first with -H "Cookie: SESSIONID=A", then with -H "Cookie: SESSIONID=B".
Expected
Each cookie value gets MISS on the first requestCommon Mistakes
- Turning on Ignore response headers for the hit ratio. Responses that carry
Set-Cookieor personal responses can be served to other users (recommended values). - Making the client IP the key in Dynamic caching. Users behind NAT share the same IP; the session cookie is preferred.
- Confusing the browser cache with the TR7 cache. The
Cache-Controlheaders added to responses manage the browser; the TR7 cache is managed with the Cache profile.
How it is done in the documentation
