How do large request bodies (file uploads) affect WAF performance?
Short answer
Large bodies affect WAF performance in three ways: waiting, CPU and memory. Waiting: to be able to inspect the body, the WAF by default waits for the whole body to arrive or for the buffer to fill up; the request is forwarded to the Backend Service after this. If Wait for Body for a Time is turned on, the wait lasts at most as long as Time to Wait Body (default 300 ms). CPU: as the body grows and becomes more complex, parsing and signature scanning take longer; in multipart uploads, the whole body (if OWASP Check is on in the Raw field), the file contents (if OWASP Check in Upload is also on) and the field values (if OWASP Check is on in the Form field) are scanned separately. Body types whose inspection is off in the page type are not parsed. Memory: the request buffer is the greater of the Max. Body Size to Process(kB) value (4096 when WAF is turned on) and the Buffer Size(kB) value in the vService Limits profile; if changing one of these values changes the buffer, the vService is restarted, so it is made in a maintenance window. A body that does not fit into the buffer or does not complete in time is not parsed and not scanned; what happens is determined by the Raw settings of the page type. In Blocking Mode, a request whose scan cannot be completed within the 2-second time limit is blocked (if Fail-open in the Request Body Limits window is on, it is let through without being scanned). For upload pages, instead of blindly enlarging the limit, keeping on only the necessary inspections in that page type and restricting the allowed file types (Allowed Upload Mime Types) is more balanced.
Effects
| Effect | Cause | Related setting |
|---|---|---|
| Waiting | The whole body or the buffer filling up is awaited | Wait for Body for a Time, Time to Wait Body (What is "Wait for body for a time" for?) |
| CPU | Parsing and scanning grow with the body | The body inspections of the page type; OWASP Check in Upload |
| Memory | Buffer = the greater of Max. Body Size to Process(kB) and Buffer Size(kB) | Max. Body Size to Process(kB) (What is the maximum value of Max. body size to process; how does it relate to the log limit?), Buffer Size(kB) (What is Buffer size used for; when should I change it?) |
| Restart | A buffer change restarts the vService | Changed in a maintenance window |
| Body that exceeds the limit | Not parsed and not scanned; the Raw settings decide | What happens to request bodies that exceed the Max. Body Size to Process(kB) limit or do not complete in time? |
| Timeout | In Blocking Mode, a request whose scan cannot be completed within the 2-second time limit is blocked; if Fail-open is on, it is let through without being scanned | What happens to a request if the scan exceeds a certain time (2-second scan limit)? |
- Setting path: Left Monitor Panel → WAF-Protected vServices → vService → WAF Management → the pencil icon of the Request Body Limits card in the Inspection & Blocking section → fields → Edit. Max. Body Size to Process(kB) takes a value between 1 and 262144.
- With WEB-CLI, the body wait time can also be limited to 300 ms.
--syncWithDefaultFwRulesis not a stored setting but a write trigger: only whentrueis 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. Thefalsein the command states this explicitly (Sync with Default WAF Rules):
waf options update poolId <vService> --syncWithDefaultFwRules false --dontBufferRequest true --waitForBodyMs.val 300 --waitForBodyMs.unit ms- Multipart scanning: In multipart requests, is the whole body scanned separately as well? · File content: Is the content of uploaded files scanned as well (OWASP Check in Upload)?
- WAF Time does not include the body wait time (What exactly does the WAF Time value measure?); in the Traffic view of WAF Report, the body size and WAF Time breakdowns are read side by side.
Common Misconceptions
- "Enlarging the limit only means more inspection." The request buffer grows, memory consumption increases and, if the buffer changes, the vService is restarted.
- "The first part of a body that exceeds the limit is scanned." The body is not parsed or scanned at all; according to the Raw settings, it is blocked or passes.
- "A file that uploads slowly hits the 2-second limit." Waiting for the body to arrive from the network is not included in the scan time.
How it is done in the documentation
