Large POST requests are blocked or cut off; why?

Short answer

The cause is distinguished by the status code and the Event Logs record. For a 418 that has a record, the most common rule is Block Unparsed Contents: the body did not fit in the inspection buffer (the larger of Buffer Size(kB) in vService Limits and the Max. Body Size to Process(kB) value; default 4096 kB) or was not completed within the wait time while Wait for body for a time is selected. This rule blocks only if Block Unparsed Body is selected in the page type the request matches: in Any Paths, Allow unparsed body is selected and such a body passes without being scanned, whereas in the page types created by Analysis & Learning, Block Unparsed Body comes selected. The other records are learned size limits: Raw Body Size, JSON Value Length, Form Value Length. For a 418 that has no record in Event Logs, it is first examined whether the scan was completed within the 2-second time limit; this block occurs only in Blocking mode, while Fail-open in the Request Body Limits window is off (default). A 408 or a request cut off midway, on the other hand, results from the WAF waiting for the body by buffering it: while Wait for body for a time is not selected (default), if the buffered portion does not arrive within HTTP Request Timeout (default 30 s), the request ends with 408.

Problem: Large POST Requests Fail

Requests that send a large form, JSON or file receive the blocking page (default status code 418), end with 408, or the connection drops while the upload is in progress. The same symptom can come from the body limits of the WAF, from the scan time limit or from the way the body is waited for; the trace of each remains on a different screen.

Possible Causes

Symptom	Cause	Solution
418; Block Unparsed Contents in Event Logs (Attack area Raw)	The body did not fit in the buffer or was not completed within the wait time, and Block unparsed body is selected in the matched page type	Method 2 or Method 3
418; Raw Body Size (Attack area Raw)	The declared size of the body (Content-Length) is outside the range of the rule	Method 1 or Method 3
418; JSON Value Length, Form Value Length, JSON Key Count, JSON Depth, Form Key Count	The length of a value or the number of keys in the body is outside the limit of the rule	Method 1
418; no record in Event Logs	In Blocking mode, the scan could not be completed within the 2-second time limit (while Fail-open is off, default)	Why does a request that received 418 not appear in Event Logs?
408 or the connection drops while the upload is in progress	The buffered portion of the body did not arrive within HTTP Request Timeout, or the client sent no data for the Client Timeout period	Large file uploads fail; why?
413 or the application's own error page	The limit is on the Backend Service (the body size limit of the web server)	Server setting

Definitive rules:

• The inspection buffer is the larger of Buffer Size(kB) in the vService Limits profile assigned to the vService and the Max. Body Size to Process(kB) value on the Request Body Limits card. Max. Body Size to Process(kB) is set between 1 and 262144; the default is 4096. A body that does not fit in the buffer is not parsed partially; it is not parsed at all.
• While Wait for body for a time is not selected (default), the whole body or as much of it as fills the buffer is waited for; this wait is subject to the HTTP Request Timeout period. While it is selected, the body is waited for at most for the Time to Wait Body period (default 300 ms); when the period expires, the incomplete body counts as unparseable and falls to the Block Unparsed Contents setting.
• Raw Body Size compares the body size before all the body inspections, independently of the content type. In Any Paths, the range is 1 – 268,435,456 bytes (256 MiB). In the page types created by Analysis & Learning, the range is widened according to the largest body seen during learning, with a minimum of 16,384 bytes; a larger request exceeds this limit.
• In Any paths, JSON Value Length is 0 – 1,048,576 and Form Value Length is 0 – 2,097,152 characters. In a multipart body, the value of the file field is not the content of the file but its name; the file size does not affect Form Value Length.
• Block Unparsed Contents, Raw Body Size and the value limits are 24-point structural violations; at every protection level, they reach the blocking threshold on their own. They block in Blocking mode, only produce a record in Monitor mode, and are not scored in Learning mode. Raw Body Size and the value limits are applied while Structure Checks on the Checks card is on (default); Block Unparsed Contents is independent of this switch.
• A body that does not fit in the buffer or is truncated is not written to the Event Logs record; the Body field does not appear in the record.

Where Is It Monitored?

Screen	Path	What it shows
Event Logs	Left Monitor Panel → WAF-Protected vServices → vService → Event Logs	On the Attacks tab, the violated limit, Corresponding rule and Learning suggestion; on the Request & Location tab, WAF time
Request Body Limits card	WAF Management → Inspection & Blocking	The body size to be processed and the body wait time (card)
HTTP Logs	Left Monitor Panel → Load Balancer vServices → vService → Logs & Tracking	Status code (418, 408, 413)
Debug Mode Logs	On the same tab (while the vService is in Debug mode)	Security action (WAF · Attack blocked — scan timed out on a timeout) and Termination state (During request · Client timeout on a 408)

How to Diagnose?

1. The status code of the error is determined; a 413 or the application's error page comes from the Backend Service.
2. For a 418, the Request ID on the user's blocking page is written in the Request Unique ID field in the server filter of Event Logs, and Save & get logs is clicked.
3. If there is a record, Attack Name on the Attacks tab is read and matched with the table above; Corresponding Rule shows the rule in which the change will be made. For Raw Body Size and the value limits, Learning Suggestion writes the old and the suggested range.
4. If there is no record or the response is 408, the Status field of the HTTP vService is set to Debug mode, the request is repeated, and Security action and Termination state are read in Debug mode logs (Why does a request that received 418 not appear in Event Logs?). When the examination is finished, Status is set back to Enabled. Turning on Debug mode requires modify permission in the Load Balancer area, and viewing Debug Mode Logs requires monitoring permission in the Load Balancer area; for a user who has only WAF permission, these screens do not open (Logs & Tracking).
5. The body size to be processed and the wait time on the Request Body Limits card, and the Block Unparsed Contents and Raw Body Size values on the Raw tab of the page type are reviewed.

Solution: Four Methods

The methods are alternatives to each other. Enlarging the buffer opens the body to scanning but increases memory usage and the scan time; selecting Allow Unparsed Body in the page type lets the body through without scanning.

Your situation	Suitable method
A Raw Body Size or value limit record; individual false positives	Method 1: Allow from Event Logs
A Block Unparsed Contents record; the large body should be scanned too, or the wait time is short	Method 2: Request Body Limits
A Block Unparsed Contents or Raw Body Size record only on a specific upload endpoint	Method 3: The Raw common rule of the page type
The setting will be made from the command line	Method 4: WEB-CLI
A 408 or a drop while the upload is in progress	Why is the request cut off during long operations (report, file upload); which timeout should I increase?
A 418 that has no record in Event Logs	What happens to a request if the scan exceeds a certain time (2-second scan limit)?

Method 1: Allow from Event Logs Recommended

• How it works The limit in the record is taught: Raw Body Size or the value limit is widened so as to cover the recorded value; for a Block Unparsed Contents record, the page type is switched to Allow Unparsed Body, and from then on a body that does not fit in the buffer passes without being scanned. The change to be made is written beforehand in the Learning Suggestion row.
• Where it is opened Left Monitor Panel → WAF-Protected vServices → vService → Event Logs → record → Attacks
• Requirement Modify permission in the WAF area; the record being present in Event Logs (host group in Monitor or Blocking mode)
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Open the Event Logs screen

In the Left Monitor Panel, the WAF-Protected vServices category is selected, the vService is clicked and the Event Logs tab is opened.

2

Adım 2 Enter the scope of the record

On the server filter tab, the Request ID is written in the Request Unique ID field, or Date Range is selected so as to cover the time of the event (server filter).

3

Adım 3 Fetch the record

Save & Get Logs is clicked.

4

Adım 4 Open the record

The row is clicked and the Attacks tab is selected in the preview; Attack Name, Corresponding Rule and Learning Suggestion are read. If the suggested range does not cover the largest expected request, the rule is edited manually with Edit Corresponding Rule instead of teaching (Method 3).

5

Adım 5 Select the attack

In the attack table, the box of the violation to be taught is checked.

6

Adım 6 Click Allow

The button above the table is clicked. The button carries the name Allow in a blocked record and Teach in a record written in Monitor mode (Allow / Teach).

7

Adım 7 Confirm

Yes is clicked in the Are you sure? question; the change is applied without a separate deployment step. In a cluster setup, the change is also sent to the peer device with the default auto-sync; if Manual Sync Mode is on, it is sent with Synchronize.

Verification

1Attacks columnTR7 side

The Attacks column of the taught record in Event Logs is examined.

ExpectedFirst number 0; row green

The first number of the column shows how many attacks the same request would trigger with the current rule set (Attacks column).

Method 2: Request Body Limits

• How it works The body size to be processed is increased or the body wait time is extended across the vService; a body that fits in the buffer and is completed in time is parsed and scanned.
• Where it is opened Left Monitor Panel → WAF-Protected vServices → vService → WAF Management → Inspection & Blocking → Request Body Limits card
• Requirement Modify permission in the WAF area
• Scope The whole vService; all host groups and page types

Step-by-Step Configuration

1

Adım 1 Open the WAF Management tab

In the Left Monitor Panel, WAF-Protected vServices is selected, the vService is clicked and the WAF Management tab is opened.

2

Adım 2 Open the Request Body Limits window

The pencil icon of the Request Body Limits card in the Inspection & Blocking section is clicked; the Request Body Limits window opens (Edit screen).

3

Adım 3 Set the limit

Record / symptom	Field
Block Unparsed Contents; the body is larger than the buffer	Max. Body Size to Process(kB) is increased so as to cover the largest expected body (1 – 262144; default 4096). As the buffer grows, the memory usage of the device and the scan time of large bodies increase (What is the maximum value of Max. body size to process; how does it relate to the log limit?)
Block Unparsed Contents; Wait for body for a time selected and a slow client	Time to Wait Body is extended or the Wait for body for a time check is removed; when the check is removed, the body is waited for during the HTTP Request Timeout period (What is "Wait for body for a time" for?)

4

Adım 4 Save

Edit is clicked; the WAF configuration is regenerated and applied without a separate deployment step. If the new value changes the request buffer (the larger of Buffer Size(kB) and this value), the vService is restarted with the save; so the change is made in a maintenance window. In a cluster setup, the change is also sent to the peer device with the default auto-sync; if Manual Sync Mode is on, it is sent with Synchronize.

Verification

1CardTR7 side

The sentences on the Request Body Limits card are examined.

ExpectedThe body size to be processed and the wait time show the new value

2RequestClient side

The large request is repeated.

ExpectedNo Block unparsed contents record is created

Since the large body is now scanned, another structural or signature violation may come to light; the record is examined with Method 1.

Method 3: The Raw Common Rule of the Page Type

• How it works For the endpoint that receives a large body, Block Unparsed Contents is set to Allow unparsed body in its own page type and the Raw Body Size range is widened; the change is applied only to this page type.
• Where it is opened Left Monitor Panel → WAF-Protected vServices → vService → WAF Management → N page types → rule → Raw tab
• Requirement Modify permission in the WAF area
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Open the Page Types screen

On the WAF Management tab, the N page types link on the mode card of the host group the request falls into is clicked (accessing the screen).

2

Adım 2 Open the page type add form (if needed)

If the Corresponding Rule in the record is Any Paths or a broad glob rule and the change is wanted only on this endpoint, Add in the toolbar is clicked. If the endpoint has a page type, the process continues with step 5.

3

Adım 3 Enter the path

The path of the endpoint is written in the Path field without wildcard characters (e.g. /api/import) (Exact path add screen).

4

Adım 4 Save the page type

Add is clicked; the page type is added to the list.

5

Adım 5 Select the rule

The row of the endpoint is clicked in the list; the detail panel opens.

6

Adım 6 Switch to the Raw tab

Raw is clicked in the tab strip of the panel.

7

Adım 7 Open the common rule form

Add Common Rule for Raw (if the rule has no Raw common rule of its own; the form opens filled with the Raw values of Any paths) or Edit Common Rule for Raw is clicked (Add common rule for Raw screen).

8

Adım 8 Set the fields

The Block Unparsed Contents switch is set to the Allow Unparsed Body position; the hint of the field shows the size of the buffer. The upper limit of the Raw Body Size range is increased, in bytes, according to the largest body on the endpoint. On a page where Allow Unparsed Body is selected, none of the JSON, XML, Form and Raw inspections is applied to a body that does not fit in the buffer; the risk is balanced by only trusted clients accessing the endpoint or by the content being validated on the Backend Service.

9

Adım 9 Save

Add or Edit in the form is clicked; the change is applied without a separate deployment step. In a cluster setup, the change is also sent to the peer device with the default auto-sync; if Manual Sync Mode is on, it is sent with Synchronize.

Verification

1Detail panelTR7 side

The Block Unparsed Contents and Raw Body Size rows on the Raw tab of the rule are examined.

ExpectedAllow unparsed body; the new range

Method 4: WEB-CLI

• How it works The WAF settings of the vService are updated with the waf options update command, and the Raw common part of the page type with the waf rule-parts update command (WEB-CLI).
• Where it is opened WEB-CLI → waf options · waf fw-rules · waf rule-parts
• Requirement WEB-CLI access and modify permission in the WAF area
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Increase the body size to be processed

The value is in kB (body processing fields):

waf options update poolId <vService> --bodyParseLimit 16384 --syncWithDefaultFwRules false

--syncWithDefaultFwRules is not a stored setting but a write trigger: only when true is written is the Any paths rule rebuilt with its default definition; if it is not written in the command, the rule set is not touched. The false in the command states this explicitly (Sync with Default WAF Rules; basic inspections).

2

Adım 2 Get the IDs of the rule and the Raw part

waf fw-rules list poolId <vService> hostGroupId <group>

waf rule-parts list poolId <vService> hostGroupId <group> ruleId <rule>

The part whose region is raw is the Raw common part. The ID of the default host group is defaultHost, and the ID of the Any paths rule is wr-default. If there is no Raw part in the list, the rule is inheriting the Raw settings; the common part is created in the interface with Add Common Rule for Raw in Method 3.

3

Adım 3 Update the Raw part

A body that does not fit in the buffer is allowed and the Raw Body Size range is widened to 50 MiB (loc raw fields):

waf rule-parts update poolId <vService> hostGroupId <group> ruleId <rule> id <part> --rawBlockUnparsed false --rawSize.op "-" --rawSize.val 1 --rawSize.val2 52428800

Verification

1SettingsTR7 side

The WAF settings of the vService and the Raw part are displayed again.

Command: waf options show poolId <vService>

ExpectedbodyParseLimit 16384

The Raw part is displayed with waf rule-parts show poolId <vService> hostGroupId <group> ruleId <rule> <part>; rawBlockUnparsed false is expected.

Common Mistakes

• Keeping the buffer larger than necessary. As the buffer grows, memory usage and the scan time of large bodies increase; in Blocking mode, a request whose scan cannot be completed within the 2-second time limit is blocked. For a single endpoint with large bodies, Allow Unparsed Body and the Raw Body Size limit in the page type are preferred.
• Thinking that the large body is scanned in Any paths. In Any paths, Allow Unparsed Body is selected; a body that does not fit in the buffer is not blocked, but it is not scanned at all.
• Taking the 408 for a WAF block. There is no blocking page and no Event Logs record; HTTP Request Timeout expired while the body was being waited for.
• Switching the host group to Monitor mode to remove the timeout block. This removes all WAF blocking in that group. First, the scanned body is made smaller; if the request cannot be made smaller, Fail-open, which removes only these blocks, is turned on (Why does a request that received 418 not appear in Event Logs?).
• Forgetting the limits in the page types produced with Analysis & Learning. Raw Body Size and the value lengths are determined according to the traffic in the learning period, and Block Unparsed Body comes selected; before larger requests go live, the limits are reviewed.

How it is done in the documentation

• Request Body Limits · Max. Body Size to Process (kB)
• Request Body Limits · Wait for Body for a Time
• RAW · Block Unparsed Contents
• RAW · Raw Body Size
• Timeouts · HTTP Request Timeout

Related questions

• What happens to request bodies that exceed the Max. Body Size to Process(kB) limit or do not complete in time?
• What is "Wait for body for a time" for?
• How do large request bodies (file uploads) affect WAF performance?
• File uploads are being blocked by the WAF; how do I fix it?