HTTP Response Body

What Is the HTTP Response Body Condition?

HTTP Response Body is a condition type used to make traffic manipulation decisions by evaluating the body content of the HTTP response coming from the Backend Service server.

The HTTP response body is the section that contains the actual content sent by the server to the client in response to an HTTP request. It is the content section that comes after the headers, following an empty line.

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 52

↓ HTTP Response Body

{"status":"success", "message":"User created"}

This condition can be evaluated only at the response stage.

WARNING

The HTTP Response Body condition works only at the Response stage. This condition cannot be evaluated before the Backend Service responds.

The Importance of the HTTP Response Body Condition

The content returned by Backend Services carries critical information about the application state, error messages and user data.

With the HTTP Response Body condition:

• Backend error messages can be detected,
• Different operations can be applied according to API response contents,
• Sensitive data leaks can be detected,
• Cache strategies can be applied according to specific contents,
• Conditions can be defined for dynamic content manipulation.

HTTP Response Body vs HTTP Request 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 only at the response (At Response) stage; the response body does not yet exist at the request stage.

How to Add?

A new HTTP Response 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 response 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 Response Body Condition Add Form

HTTP Response 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 response 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	"error"	Responses containing errors
Regex	"status"\s*:\s*"fail"	Failed API responses
Includes	<!DOCTYPE html>	HTML pages
Includes	stack trace	Responses leaking error details

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:

• "error":true: JSON error responses
• Exception: Java stack trace
• <title>Error</title>: HTML error pages
• password: Password information leak

INFO

Body Size to Parse(Bytes)

How many bytes of the HTTP response 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.

Response Delay

In order for the response body to be inspected, TR7 holds the response before forwarding it to the client until the target number of bytes is collected; the upper limit of this wait is 500 ms and cannot be changed. When the time expires, the response is not cut: the condition is evaluated on the partial body collected up to that moment; if the searched content has not arrived yet, the condition silently does not match. The probability of waiting is higher in (chunked) responses that do not declare Content-Length. This delay cost arises across the vService: if there is more than one body condition, the target is the largest Body size value among the conditions.

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

• It Should Be Used for Error Detection. This condition should be used to detect backend errors and show custom error pages.
• Data Leak Control. Responses leaking stack traces, passwords or sensitive data should be detected and blocked.
• 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 Compressed Content. Text pattern matching is not reliable in compressed responses, and TR7 does not automatically disable compression for this condition; it should be ensured that the compression profile is disabled in the vService in which the condition is used.

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: Blocking Stack Trace Leaks (Production Environment)

Purpose: To prevent debug information such as stack traces and exception details in Backend Service responses from being visible to users in the production environment, and to close the security vulnerability.

Configuration: Content Matching Method → Regex · Case insensitive → checked · Query → (Exception|stack trace|at .+\(.+\.(java|py|php):[0-9]+\)|Traceback) · Body size to parse → 8192

Action Recommendations:

• ✅ Show Content → The response containing a stack trace is blocked, and a generic "500 Internal Server Error" page is shown to the user.
• ✅ Delete HTTP Header → Sensitive debug headers such as X-Debug and X-Error-Detail are removed from the response.

Scenario 2: Sensitive Data Leak Detection and Blocking

Purpose: To detect and block sensitive data such as passwords, API keys and tokens from leaking to users by mistake in Backend Service responses.

Configuration: Content Matching Method → Regex · Case insensitive → checked · Query → (password|secret|api_key|private_key|token|credential) · Body size to parse → 8192

Action Recommendations:

• ✅ Show Content → The response containing sensitive data is blocked, and the redacted response "Sensitive data removed" is shown.
• ✅ Add HTTP Header → The X-Security-Alert: data-leak header is added, and the security event is marked.

Scenario 3: SQL Error Message Masking

Purpose: To prevent information leaks about the database structure by hiding database error messages (MySQL, PostgreSQL, Oracle) in Backend Service responses.

Configuration: Content Matching Method → Regex · Case insensitive → checked · Query → (SQL syntax|mysql_|pg_|ORA-[0-9]+|SQLite) · Body size to parse → 4096

Action Recommendations:

• ✅ Show Content → The SQL error message is hidden, and a generic "Database error occurred" message is shown to the user.