Skip to content
Smarter by Design.Simpler for Business

Request Size (bytes) ​

What Is the Request Size (bytes) Condition? ​

Request Size (bytes) is a condition type used to make traffic routing and manipulation decisions by evaluating the byte length of the first part of the HTTP request that reaches TR7.

The measured value is the byte length of the first part of the request that reaches TR7: the header block and the part of the body buffered up to that moment. Since the request body is not buffered in its entirety, the condition does not see the total size of large bodies and does not read the Content-Length header.

POST /api/upload HTTP/1.1
Host: www.example.com
Content-Type: multipart/form-data
Content-Length: 1048576
[ header block + buffered part of the body ]
Evaluated: the first part of the request reaching TR7

This condition is used to detect large requests and subject them to special processing.

WARNING

The size is measured at the time of the request; the condition can also be selected in rules at the response stage and is evaluated over the same value.

The Importance of the Request Size (bytes) Condition ​

Request size control is critically important for resource management, security and performance optimization.

With the Request Size (bytes) condition:

  • Requests carrying an unusually large header block can be blocked, and resource consumption can be prevented,
  • Requests whose buffered content exceeds a specific size can be distinguished,
  • Large requests can be routed to different Backend Services,
  • Bandwidth management can be performed,
  • It can be used as an additional criterion for rate limiting.

Request Size (bytes) vs Response Size (bytes):

CriterionRequest Size (bytes)Response Size (bytes)
DirectionClient → ServerServer → Client
MeasuredHeader block + buffered part of the bodyOnly the response body (headers excluded)
EvaluationRequest stageResponse stage

Supported vService Types ​

HTTP
L7 TCP
Network

How to Add? ​

A new Request Size (bytes) 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. Request size (bytes) is selected as Criteria.
  4. The related configurations of the condition are made.
  5. The condition is added by clicking the Add button.

Request Size (bytes) Condition Add Form ​

Request Size (bytes) Condition Add FormRequest Size (bytes) 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; Request size (bytes) 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

Operator ​

The numeric comparison operator and value are entered.

OperatorSymbolDescription
Less than<The value must be less
Equals to=The value must match exactly
Greater than>The value must be greater
Range-The value must be between two values

Sample request size comparisons:

OperatorValueDescription
>1048576Requests larger than 1 MB
<1024Requests smaller than 1 KB
-10240-102400Between 10 KB and 100 KB
<512Very small requests (with minimal headers)

Common size references:

UnitBytes
1 KB1024
10 KB10240
100 KB102400
1 MB1048576
10 MB10485760
100 MB104857600

TIP

When the Range (-) operator is selected, two values are entered; both boundaries are included in the range. The form opens with the operator Equals to (=) selected and the value empty; the entered value must be an integer. The entered byte values appear with a readable unit in the automatic description (e.g. 1048576 → 1 MB).

WARNING

Since the request is not buffered in its entirety, the upper limit that can be evaluated in practice is limited by the buffer size of the vService; thresholds in the MB range never match in most installations. Thresholds should be selected from realistic values (in the KB range) that remain within the header block + buffer scope.

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 measured request size can be used in actions with the Request size smart variable (e.g. as the value of an HTTP header or a log field).

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 AddedCondition Added

Operational Usage Recommendations ​

  • It Should Not Be Used for Total Upload Size. Since the condition does not see the whole body, it does not limit large file uploads by total size; the threshold should be determined over the header block and the buffered part.
  • DoS Protection. Resource consumption should be prevented by blocking very large requests.
  • Routing According to Backend Capacity. Large requests should be routed to more powerful Backend Services.
  • It Should Be Used for Monitoring. Usage patterns should be understood by monitoring requests in a specific size range.

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 Abnormally Large Requests ​

Purpose: To prevent resource consumption by blocking requests that carry an unusually large header block/first part (inflated headers, abnormal form submissions).

Configuration: Operator → Greater than (>) 16384

Action Recommendations:

  • ✅ Block → Abnormally large requests are blocked; 413 Payload Too Large can be selected as the response code (default 403 Forbidden).
  • ✅ Show Content → The custom error page "Request size limit exceeded" is shown.

Scenario 2: Bandwidth Limitation for Large File Uploads ​

Purpose: To apply bandwidth limitation to large form/upload entries and protect network resources.

Configuration: Operator → Range (-) 8192-16384 (above this, the blocking in Scenario 1 takes over)

Action Recommendations:

  • ✅ Bandwidth Limitation → The upload speed is limited to 5 Mbps, and network congestion is prevented.

Scenario 3: Form Submit Size Validation ​

Purpose: To detect form submissions according to the size range and apply validation.

Configuration: Operator → Range (-) 1024-8192

Action Recommendations:

  • ✅ Add HTTP Header → The X-Form-Submit: true and Content-Length-Valid: true headers are added.
  • ✅ Manage HTTP Security Headers → The X-Content-Type-Options: nosniff header is added, and form security is increased.

Scenario 4: Detection of Very Small Requests ​

Purpose: To mark requests that come with minimal headers and are smaller than ordinary browser traffic (simple automation clients, health checks). Even a GET request without a body is not 0 bytes because of the headers; for this reason, a low threshold is used instead of = 0 for an "empty request".

Configuration: Operator → Less than (<) 512

Action Recommendations:

  • ✅ Add HTTP Header → The X-Minimal-Request: true header is added; the Backend Service distinguishes this traffic.
  • ✅ Advanced Traffic Inspection → The minimal request profile and source distribution are reported.