Smarter by Design.Simpler for Business
TR7Enterprise Application Delivery & Security Platform
What is the difference between New Cookie and Current Cookie?
Short answer
When New Cookie is selected in the Persistence field of an HTTP vService, TR7 adds its own cookie to the response (named TR-C if Cookie Name is empty); it works independently of the application, and the idle (Cookie Max-Idle, default 30 min) and total lifetime (Cookie Max-Life, default 8 hours) durations of the cookie are set. With Current Cookie, TR7 does not add a new cookie; it adds a marker that identifies the Backend Service in front of the value of the session cookie generated by the application (e.g. JSESSIONID, PHPSESSID), and persistence lasts as long as the application's session. In both methods, the marker is the Cookie Content value of the Backend Service.
Comparison
| New Cookie | Current Cookie | |
|---|---|---|
| Who generates the cookie | TR7 | The application |
| Cookie name | Cookie Name; optional, TR-C if empty | Cookie Name; required, the cookie name of the application |
| What the client sees | TR-C=<server-value> | JSESSIONID=<server-value>~<application-value> |
| What is forwarded to the application | The cookie of TR7 is not forwarded | The original value with the prefix removed |
| Durations | Cookie Max-Idle (default 30 min; 60 s – 7 days) · Cookie Max-Life (default 8 hours; 10 min – 30 days) | The session duration of the application |
| First request | The algorithm selects the server, and the cookie is added in the first response | The algorithm selects until the application sets the cookie |
| Suitable case | New applications; application-independent persistence | Existing applications that have their own session cookie |
Where Does the Server Value Come From?
In both methods, the value that identifies the server is the Cookie Content field of the Backend Service; the field has no default value, and while it is empty, TR7 generates the value automatically from the address of the server. In a Backend Group, the value is entered per row.
If the Server Goes Down
If the server the cookie points to becomes Error in the health check or is put into Maintenance Mode, the request goes to a healthy server and the client is given the marker of the new server. If no health check is assigned to the server, TR7 never considers it unavailable.
Cookie Security
TR7 does not set the Secure, HttpOnly or SameSite flag on the cookie added by New Cookie. If these flags are required, there are two ways: the Security Flags field of Session Affinity Manager (SAM) (default HttpOnly and Secure (HTTPS only)), or the Mark as Only HTTP, Mark as Secure and Cookie Attribute fields of the Cookie Based Connection Persistency action, which is used with the Persistence field of the vService left as None.
In TR7
- Location: Load Balancer → Load Balancer vService List → HTTP vService → Edit → Details → LB Algorithm box → Persistence → New Cookie or Current Cookie (Persistence); it is saved with Save.
- Fields: With New Cookie, Cookie Name (optional), Cookie Max-Idle and Cookie Max-Life appear; with Current Cookie, only Cookie Name (required) appears.
- Cluster: While Clustering is on and Manual Sync Mode is off (default), the setting is transferred to the peer device automatically; since the information is carried in the cookie, the client goes to the same Backend Service whichever device it comes to.
- While a self-persistent algorithm is selected, the Persistence field does not appear.
- WEB-CLI:
--persistence tr7Cookie(New Cookie) or--persistence serverCookie(Current Cookie).
Common Misconceptions
- "Current Cookie does not touch the cookie of the application." A server marker is added in front of the value the client sees; this marker is removed on the way to the application.
- "A cookie name is required for New Cookie." It is optional in the panel; if it is empty,
TR-Cis used. - "With Current Cookie, a duration is set." Cookie Max-Idle and max-life exist only with New Cookie.
- "Cookie persistence also works with API clients." It does not work with clients that do not store cookies; Hash is used for these clients (How is persistence achieved for clients that do not support cookies (mobile apps, API clients)?).
How it is done in the documentation
