Server Cookie Name

What Is the Server Cookie Name Condition?

Server Cookie Name is a condition type used to make traffic routing and manipulation decisions by checking the Set-Cookie header in the HTTP response returned from the Backend Service.

Cookies are small pieces of data used to store and carry state information between the client (browser) and the server. Since HTTP is stateless, session and user tracking is provided with cookies.

The server uses this cookie for:

• Session tracking,
• Authentication,
• Authorization,
• Security checks.

How Is It Created?

The server sends Set-Cookie in the response header:

Set-Cookie: session_id=abc123; Path=/; HttpOnly; Secure

Browser:

It stores the cookie and sends it back automatically in the next request made for the same domain/path.

Cookie: session_id=abc123

Server Response

HTTP/1.1 200 OK
Set-Cookie: session_id=new123; Path=/; HttpOnly
Set-Cookie: tracking=abc; Domain=.example.com

Server Cookies

This condition can be evaluated only at the response stage.

WARNING

The Server Cookie Name condition works only at the Response stage. This condition cannot be evaluated before the Backend Service responds.

The Importance of the Server Cookie Name Condition

The cookies sent by Backend Services are critically important for session creation, authorization and state management.

With the Server Cookie Name condition:

• Whether the backend has created a session can be checked,
• Caching strategies can be applied according to specific cookie values,
• Cookie-based routing decisions can be made,
• Conditions can be defined for cookie manipulation.

Server Cookie vs User Cookie:

Criterion	Server Cookie	User Cookie
Direction	Response	Request
Header	Set-Cookie	Cookie
Usage	Server → Client	Client → Server
Evaluation	Response stage only	Request + Response stage (the value is read from the request)

Supported vService Types

HTTP

L7 TCP

Network

How to Add?

A new Server Cookie Name Condition can be added through the TR7 web management interface by following the steps below:

1. The Configuration Menu is opened by clicking the TR7 logo at the bottom left.
2. The Load Balancer → Conditions → Add steps are followed.
3. Server cookie name is selected as Criteria.
4. The related configurations of the condition are made.
5. The condition is added by clicking the Add button.

Server Cookie Name Condition Add Form

Server Cookie Name Condition Add Form

INFO

Condition Name

An optional name can be entered for the condition to be created.

This field is especially important in the following scenarios:

• When many conditions are defined under the same vService,
• When conditions with similar criteria need to be distinguished,
• When it is necessary to quickly understand which business rule the condition represents.

When this field is left empty, TR7 analyzes the content of the related condition and creates an automatic, descriptive name in the Condition Description field. This generated description is used as the name in condition lists.

INFO

Criteria Required

The field that determines the type of the condition; Server cookie name is selected from the searchable dropdown list. This selection determines the fields displayed in the form. The criterion cannot be changed after the condition is saved: if a different criterion is needed, a new condition is defined. For all criteria in the list and their scopes, the criteria catalog on the Conditions page can be referred to.

INFO

Cookie Name Required

The name of the server cookie to be checked is entered in this field.

Common Server Cookie Examples:

Cookie Name	Typical Usage
session_id	Creating a new session
JSESSIONID	Starting a Java session
auth_token	Authentication token
csrf_token	CSRF protection
server_id	Sticky session

INFO

Content Matching Method Default: Exact match

Determines how the content is matched. The field appears in the form as an unlabeled dropdown list right below Criteria and opens with Exact match selected.

Option	Code	Description
Exact match	exactMatch	The value must match exactly.
Start	start	The value must start with the specified text.
End	end	The value must end with the specified text.
Includes	sub	The value must contain the specified text.
Regex	regex	The value must match the regular expression.
Is present	found	Only a presence check is performed. (the value does not matter)

TIP

When Is present is selected, whether the server sends this cookie is checked; its value does not matter. With this selection, the Query and Case Insensitive fields are hidden.

Example: detecting whether the backend creates a new session.

INFO

Case Insensitive Default: Off

Controls case sensitivity.

• Active: example, EXAMPLE, Example are considered the same
• Not Active: An exact match is required (default)

INFO

Query Required

The value to be matched is entered in this field. According to the selected matching method:

• Exact match: Checks for an exact match of the value.
• Start: Checks the beginning of the text to be searched for.
• End: Checks the end of the text to be searched for.
• Includes: Checks whether the text to be searched for is contained.
• Regex: Checks with a regular expression pattern (Regex).

This field is hidden when Is present is selected.

Sample Values:

• server1: Checking a specific server ID
• ^[a-zA-Z0-9]{32}$: Session ID format regex
• true: Boolean value check

INFO

Condition Description

It is created automatically by TR7 in line with the entered criteria and values.

This description:

• which value the condition applies to,
• which criterion it works on,
• the quick understanding of the condition on listing screens

is produced dynamically by the system so as to provide these.

TIP

The matching is done on the value of the cookie: Cookie Name only selects which cookie is read, and Query compares the value of that cookie. The value of the server cookie can also be used in actions with the Response cookie content smart variable, by giving the cookie name.

INFO

Form Buttons

Add

The condition adding process is completed by clicking the Add button.

Add & Repeat

With the Add & Repeat button, the condition adding process is completed, and another new condition can be added with different configurations without leaving the related window.

Condition Added

Operational Usage Recommendations

• New Session Detection. Is present should be used to detect whether the backend creates a new session.
• Sticky Session Verification. It should be verified that sticky session works correctly by checking server ID cookies.
• It Should Be Used at the Response Stage. This condition works only at the response stage. It cannot be used at the request stage.
• Attention to Set-Cookie Attributes. The Set-Cookie header also contains attributes such as Path, Domain, Secure and HttpOnly; however, the matching is done only on the value of the cookie: the attributes are not included in the comparison.

Common Usage Scenarios in Live Environments

The examples below show how the related condition is applied in the most frequently encountered use cases in real systems. These scenarios are based on practices that are widely preferred in live environments and rest on experience gained in the field.

Scenario 1: Detection of New Session Creation

Purpose: To detect whether the Backend Service starts a new session and apply cache bypass and security measures.

Configuration: Cookie name → session_id · Content Matching Method → Is present

Action Recommendations:

• ✅ Cookie Encryption → The session cookie is encrypted, and session security is increased.
• ✅ HTTP Cookie Security → The HttpOnly, Secure and SameSite attributes are added, and XSS and CSRF protection is provided.

Scenario 2: Authentication Token Format Validation

Purpose: To validate the format of the auth token sent by the Backend Service and clean up faulty tokens.

Configuration: Cookie name → auth_token · Content Matching Method → Regex · Query → ^[a-f0-9]{64}$

Action Recommendations:

• ✅ Delete HTTP Header → The Set-Cookie header containing a badly formatted token is removed, and security is ensured.
• ✅ Manage HTTP Security Headers → The X-Token-Invalid: true header is added, and the Backend Service is warned.

Scenario 3: CSRF Token Detection and Security

Purpose: To check whether the Backend Service sends a token for CSRF protection and add security headers.

Configuration: Cookie name → csrf_token · Content Matching Method → Is present

Action Recommendations:

• ✅ Manage HTTP Security Headers → The X-CSRF-Protected: true and X-Frame-Options: SAMEORIGIN headers are added.
• ✅ CORS → CORS headers are edited in CSRF-protected responses, and cross-origin security is provided.
• ✅ Add HTTP Header → The X-Content-Type-Options: nosniff header is added, and additional security is provided.

Scenario 4: Remember Me Cookie Security

Purpose: To detect the persistent login cookie, edit its security attributes and monitor the metrics.

Configuration: Cookie name → remember_me · Content Matching Method → Is present

Action Recommendations:

• ✅ Set HTTP Header → The Max-Age=2592000 (30 days) and Secure attributes are added to the remember me cookie.
• ✅ HTTP Cookie Security → The HttpOnly and SameSite=Strict attributes are added, and long-term session security is provided.