HTTP Request Body

What Is the HTTP Request Body Condition?

HTTP Request Body is a condition type used to make traffic routing and manipulation decisions by evaluating the body content of the HTTP request.

The HTTP request body is the section that contains the actual data sent by the client (browser, mobile application, API client, etc.) to the server. It is the data section that comes after the headers, following an empty line.

POST /api/users HTTP/1.1
Host: www.example.com
Content-Type: application/json
Content-Length: 45

↓ HTTP Request Body

{"username":"john","password":"secret12345"}

This condition is used to check HTTP requests that contain a body, such as POST, PUT and PATCH.

WARNING

Checking the request body requires the whole body to be kept in memory. For this reason, the body size to be checked should be limited with the Body Size to Parse(Bytes) setting.

The Importance of the HTTP Request Body Condition

In modern APIs and web applications, the request body carries user data, form contents and API payloads.

With the HTTP Request Body condition:

• JSON/XML payloads can be filtered based on content,
• Form data can be checked,
• Requests containing sensitive data can be detected,
• Requests with specific patterns can be processed differently,
• Security filters can be applied.

HTTP Request Body vs HTTP Response Body

Criterion	HTTP Request Body	HTTP Response Body
Direction	Client → Server	Server → Client
Content	Form, JSON, XML	HTML, JSON, File
Evaluation	Request + Response stage	Response stage only

Supported vService Types

HTTP

L7 TCP

Network

The condition can be used at both the request (At Request) and response (At Response) stages; the body is read at the time of the request and can also be evaluated over the same value at the response stage.

How to Add?

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

HTTP Request Body Condition Add Form

HTTP Request Body 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 request body 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. The Is present option is not offered in this criterion.

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.

Sample Body Matches:

Method	Query	Matching Bodies
Includes	"admin"	The word admin in JSON
Regex	"role"\s*:\s*"admin"	JSON role:admin
Start	<?xml	XML documents
Includes	password	Requests containing a password

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.

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

Sample values:

• "admin":true: Admin authorization check
• <script>: XSS payload detection
• SELECT.*FROM: SQL injection regex
• password: Requests containing a password field

INFO

Body Size to Parse(Bytes)

How many bytes of the HTTP request body are checked is determined; only the first N bytes of the body specified in this field are examined, and the rest is not evaluated at all.

Value	Description
Minimum	1 byte
Maximum	16384 bytes (16 KB)
Default	1024 bytes (form opening value; if the field is left empty, the system uses 4096)

TIP

For performance, the lowest possible value should be used; the searched pattern is usually at the beginning of the body.

WARNING

Body inspection requires request buffering on the vService, and its cost arises across the vService: if there is more than one body condition in the same vService, requests are buffered up to the largest Body size value among these conditions. Even if a high value such as 16 KB is given for a single condition, it affects all requests in that vService.

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

• Body Size Should Be Optimized. An unnecessarily high body size should not be set. The searched pattern will usually be at the beginning or in a specific section of the body.
• It Should Be Used for Security Scanning. Regex should be used to detect attack patterns such as SQL injection and XSS.
• Attention to JSON/XML Structure. There may be whitespace differences in JSON and XML. Flexible patterns such as \s* should be used when writing regex.
• It Does Not Work in GET Requests. GET requests usually do not contain a body. This condition is meaningful in methods such as POST, PUT and PATCH.

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: SQL Injection Attack Detection and Blocking

Purpose: To block database attacks by detecting SQL injection patterns in the HTTP request body, and to protect application security.

Configuration: Content Matching Method → Regex · Case insensitive → checked · Query → (SELECT|INSERT|UPDATE|DELETE|DROP|UNION).*FROM · Body size to parse → 4096

Action Recommendations:

• ✅ Block → When an SQL injection pattern is detected, the request is blocked with 403 Forbidden.

Scenario 2: XSS (Cross-Site Scripting) Attack Detection

Purpose: To block client-side attacks by detecting XSS payloads in the HTTP request body, and to ensure user security.

Configuration: Content Matching Method → Regex · Case insensitive → checked · Query → <script|javascript:|onerror=|onload= · Body size to parse → 4096

Action Recommendations:

• ✅ Show Content → When an XSS pattern is detected, the request is blocked, and the redacted response "An unexpected request was made." is shown.

Scenario 3: Detection of Requests Containing Sensitive Data

Purpose: To detect requests carrying sensitive data such as passwords and credit cards in the request body, and to prevent them from being sent over unencrypted (HTTP) connections.

Configuration: Content Matching Method → Regex · Case insensitive → checked · Query → (password|credit_card|ssn|cvv) · Body size to parse → 8192

Action Recommendations:

• ✅ Block → If sensitive data is being sent over the HTTP protocol, the request is blocked, and HTTPS is enforced.
• ✅ Add HTTP Header → The X-Contains-PII: true header is added, and the Backend Service knows that sensitive data is present.