HTTP Header

What Is the HTTP Header Condition?

HTTP Header is a condition type used to make traffic routing and manipulation decisions by evaluating the header information of the HTTP request or response.

HTTP headers are additional meta information carried during the HTTP requests and responses between the client (browser, mobile application, etc.) and the server. HTTP headers are not the data itself; they describe how the data is sent, how it is processed and how it is interpreted.

HTTP headers carry request and response metadata.

Sample Request HTTP Headers

GET /api/users HTTP/1.1
Host: www.tr7.com
User-Agent: Mozilla/5.0
Accept: application/json
Authorization: Bearer token123

Sample Response HTTP Headers

Content-Type: application/json
Content-Length: 348
Cache-Control: max-age=3600
Server: Apache/2.4.59 (Debian)
Set-Cookie: sessionid=abc123

This condition can check both request and response headers.

The Importance of the HTTP Header Condition

HTTP headers carry critical information such as client information, authentication, content type and cache directives.

With the HTTP Header condition:

• Virtual hosting can be performed according to the Host header,
• Browser/device detection can be performed with User-Agent,
• Authentication checks can be performed with the Authorization header,
• Special routing scenarios can be applied with custom headers,
• Different operations can be performed according to Content-Type.

In this respect, the HTTP Header condition is one of the most flexible and powerful condition types.

Supported vService Types

HTTP

L7 TCP

Network

How to Add?

A new HTTP Header 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. HTTP header is selected as Criteria.
4. The related configurations of the condition are made.
5. The condition is added by clicking the Add button.

HTTP Header Condition Add Form

HTTP Header 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; HTTP header 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

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	Description
Exact match	The value must match exactly.
Start	The value must start with the specified text.
End	The value must end with the specified text.
Includes	The value must contain the specified text.
Regex	The value must match the regular expression.
Is present	Only a presence check is performed. (the value does not matter)

TIP

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

Example: checking the presence of the Authorization header.

INFO

Case Insensitive Default: Off

Controls case sensitivity.

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

TIP

URL paths and header names should usually be processed case-insensitively, while values should remain case-sensitive.

TIP

In HTTP/1.x, header names are case-insensitive (RFC 7230). However, values are usually case-sensitive.

INFO

Header Name Required

The name of the HTTP header to be checked is entered in this field. The direction of the header is determined as Request or Response from the selector to the left of the field; the form opens with Request selected and Host written. There is no separate Condition level field in this criterion: the request/response distinction is made only in this selector.

Request

Selected for HTTP request headers.

Common request headers:

Header	Description
Host	Target domain
User-Agent	Browser/device information
Authorization	Authentication
Content-Type	Request content type
Accept	Accepted content types
X-Forwarded-For	Real IP behind a proxy
Cookie	Cookie information

Response

Selected for HTTP response headers.

Common response headers:

Header	Description
Content-Type	Response content type
Cache-Control	Cache directives
Set-Cookie	Cookie setting
Location	Redirect target

TIP

While a header name is being typed, TR7 suggests common header names as autocomplete; the suggestion list changes according to the selected direction (Request/Response). Custom header names can also be entered manually.

WARNING

A header condition with Response selected should be used only in rules and actions evaluated at the response stage; in a use at the request stage, since the header value has not been formed yet, the condition never matches.

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).

TIP

This field is hidden when Is present is selected.

Sample values:

• www.tr7.com: for the Host header
• application/json: for Content-Type
• ^Bearer\s+: Authorization regex

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.

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

• The Host Header Should Be Used for Virtual Hosting. For multiple domains on the same IP, routing should be performed according to the Host header.
• X-Forwarded-For Should Be Used Safely. X-Forwarded-For should be used for the real IP behind a proxy/CDN, but the risk of spoofing should not be forgotten.
• A Standard Prefix Should Be Used for Custom Headers. The X- prefix should be used for custom headers (e.g. X-Custom-Header).
• Response Headers Should Be Used at the Response Stage. Response headers are formed only after the Backend Service responds; a Response header condition used in a rule at the request stage never matches.

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: Multi-Domain Management with Virtual Hosting

Purpose: To serve multiple domains on the same IP address and vService and route to different Backend Services according to the Host header.

Configuration:

• Content Matching Method: Exact match
• Case Insensitive: checked
• Header Name: Request → Host
• Query: www.tr7.com

Related: With Conditional Backend Services, routing to a different Backend Service according to Host is performed.

Scenario 2: API Authentication Check

Purpose: To check the presence of the Authorization header for access to API endpoints and block unauthorized access.

Configuration:

• Content Matching Method: Is present
• Header Name: Request → Authorization

Action Recommendations:

• ✅ Block → Requests without the Authorization header are blocked with 401 Unauthorized (together with the Path condition: /api/private/).
• ✅ Show Content → The custom warning page "Authentication required" is shown.
• ✅ Quarantine → Repeated unauthorized access attempts (>10 attempts) are quarantined for 30 minutes.

Scenario 3: Mobile Device Detection and Optimization

Purpose: To detect mobile devices from the User-Agent header, route them to mobile-optimized content and improve the mobile user experience.

Configuration:

• Content Matching Method: Includes
• Case Insensitive: checked
• Header Name: Request → User-Agent
• Query: Mobile

Action Recommendations:

• ✅ Set Path → Home page (/) requests are redirected to the mobile version (/m/).
• ✅ Add HTTP Header → The X-Device-Type: mobile header is added, and the Backend Service returns a mobile-optimized response.

Scenario 4: JSON API Request Validation

Purpose: To accept only requests in JSON format by checking the Content-Type header of the requests coming to API endpoints, and to block faulty requests.

Configuration:

• Content Matching Method: Includes
• Header Name: Request → Content-Type
• Query: application/json

Action Recommendations:

• ✅ Block → POST/PUT requests are blocked with 400 Bad Request if their Content-Type is not application/json (Path condition: /api/).
• ✅ Add HTTP Header → The X-Content-Validated: true header is added, and it is marked that the JSON validation succeeded.

Scenario 5: Referer-Based Hotlink Protection

Purpose: To prevent static files (images, videos) from being linked directly from other sites (hotlinking) by checking the Referer header, and to prevent bandwidth theft.

Configuration:

• Content Matching Method: Includes
• Header Name: Request → Referer
• Query: tr7.com

Action Recommendations:

• ✅ Block → If the Referer does not contain tr7.com, static content requests are blocked with 403 Forbidden (Path condition: /images/, /videos/).
• ✅ Show Content → The warning page "Direct linking not allowed" is shown.

Scenario 6: API Version Routing

Purpose: To route to different API versions according to the custom X-API-Version header and manage API versioning.

Configuration:

• Content Matching Method: Exact match
• Header Name: Request → X-API-Version
• Query: v2

Action Recommendations:

• ✅ Set Path → A version prefix is added to the API path (/v2/endpoint), and the Backend Service processes the correct version.
• ✅ Add HTTP Header → For the old version (v1), the X-API-Deprecated: true header is added, and a deprecation warning is given.