Traditional Layer 7 traffic management typically decides on URL, method, headers and source address. That model is often enough for classic web applications, but in modern API architectures the critical distinction usually sits in fields inside the request body. Tenant identity, user role, transaction type, service name or file upload metadata are not in headers — they are in JSON, XML, form or multipart payloads.
Without that visibility, operators are pushed toward bad options. Either an additional API gateway is placed in front of traffic management — adding a new hop, new license and new operational burden — or the application itself is changed to lift the decision value into headers. For legacy and business-critical backends, that change is often not feasible.
Limiting body inspection to security alone does not solve the problem either. If the WAAP can read the content but the routing engine cannot use the same value, security policy and traffic policy end up in two separate worlds. The result is duplicated logic, inconsistent rules and an increased chance of error.
The right model is to make body parser capabilities a native part of the rule language. JSONPath, XPath, form parameters, JWT claims, regex and map/list checks should live in the same expression tree, and a single expression should drive both a traffic action and a WAAP score.
TR7 Content-Aware Rules close this gap: fields inside the body stop being merely inspected data and become signals that directly drive the decision.
TR7 does not treat content awareness as a separate add-on. It is a native part of the traffic and security rule language.
JSONQUERY, XMLQUERY, XMLPATHEXISTS, PARAM, JWTHEADER and JWTPAYLOAD are first-class functions in the rule language. Operators turn body content into conditions without writing custom code and bind those conditions directly to traffic or security actions.
JSON, XML and multipart payloads are parsed at runtime and exposed to the rule engine as readable values. Operators decide on meaningful fields instead of running blunt regex across every byte of the request.
In TR7, an expression written against a body field can drive routing, header manipulation and WAAP signature scoring alike. This shared model reduces duplicated logic between traffic rules and security rules.
In ADC mode the body can be read and, in suitable scenarios, rewritten on the response side. In WAAP mode the body is never modified — it is read, scored and blocked when the policy threshold is exceeded.
Content-Aware Rules turn structured payload data into readable conditions and enforceable actions.
The JSONQUERY function evaluates JSON body fields using standard JSONPath semantics. Operators can use values such as `$.user.role`, `$.items[0].sku` or `$.tenant_id` as conditions and bind them to vService routing, header manipulation or WAAP scoring. API traffic is no longer steered only by endpoint — it is steered by the actual business meaning of the request.
XMLQUERY, XMLPATHTYPE and XMLPATHEXISTS run XPath queries against XML bodies. The service name, action node or operation field inside a SOAP envelope can drive routing and security decisions. This is particularly valuable for applying service-level dispatch and policy without modifying legacy backends. XML payloads become structured data inside the rule engine, reducing reliance on brittle regex.
The PARAM function turns query strings, form-encoded bodies and form fields into rule conditions. The multipart parser exposes file upload metadata — field name, content type and size — to policy. This pattern is useful for SaaS portals, document upload flows and user-specific transaction logic. Traffic can be routed or blocked based on the business context the form carries.
JWTHEADER and JWTPAYLOAD expose token header and payload fields as JSONPath-queryable values. User role, tenant, authorization level or custom claims become inputs to traffic and security decisions. A required claim can be enforced at the edge, missing claims can fail the request, and role-based traffic can be steered to dedicated backend groups — all without embedding access logic in the application code.
MAP_STR, MAP_REG, MAP_SUB, MAP_IP, MAP_BEG and MAP_END provide fast lookups against large value sets. LIST_STR, LIST_REG, LIST_SUB, LIST_IP, LIST_BEG and LIST_END offer the same model for list-based checks. Tenant rosters, allowed service names, IP ranges and pattern groups can be managed centrally instead of as one-off conditions, keeping large rule sets maintainable.
BODY_SIZE, JSON_DEPTH, XML_DEPTH, JSON_KEY_COUNT and XML_NODE_COUNT define protective limits before the parser engages. Oversized, deeply nested or inflated payloads are rejected before they reach the backend. JSON_DEPTH defaults to 32 and is tunable at policy level. The same control governs both resource consumption and parser-level abuse.
JSON_MUST_ARGS, JSON_ALLOWED_ARGS, FORM_MUST_ARGS and FORM_ALLOWED_ARGS verify expected fields are present and unexpected fields are absent. Instead of only searching for bad patterns, the model declares the shape of an acceptable request. Missing required fields or unexpected parameters can be rejected per policy. This contract-aware approach is especially valuable on critical transactional endpoints.
In ADC mode, the modifyResponse action applies regex-based substitution to response bodies. It is used for masking personal data, rewriting links or adapting internal addresses for external consumers. WAAP mode never modifies the body — it only reads and scores. This separation balances traffic flexibility with security integrity on the same platform.
Content awareness is not just rule syntax — it also covers buffer management, parse caching, audit visibility and edge-case behavior.
Body content is buffered before parsing, and the relevant JSON, XML or multipart parser then runs on that buffer. The default body buffer is 16 KB; system parameters can be raised for larger JSON or XML payloads. When the limit is exceeded, the request is rejected with 413 so the backend is not loaded with oversized payloads.
JSONPath and XPath results read within the same request are cached in the transaction-scoped variable space. Once a rule reads a body field, subsequent rules do not re-run the parser for the same field. This reduces latency and processing cost in long rule chains.
In WAAP mode the body is read but never modified. The content feeds signatures, scoring and the threshold logic; once the threshold is exceeded the request is blocked. The security layer can act on content-aware signals while preserving request integrity end-to-end.
Parsing of chunked POST requests starts after chunk reassembly completes, so body fields are evaluated as a complete, coherent payload. Chunked traffic may incur a small additional latency, but the backend is shielded from partial and uncontrolled payload streams.
GraphQL is currently handled through JSONPath: fields such as operation name and field list inside the body can be used in rule conditions. This enables practical edge decisions such as splitting mutations from queries. Deep schema validation is out of scope for this capability.
Which rule read which body field is recorded in the audit log. Operations teams can trace why a specific request was routed, rejected or scored in their SIEM. This traceability prevents content-aware rules from behaving like a black box.
SaaS teams can dispatch traffic to separate backend pools based on the tenant_id field inside the JSON body. Tenant separation happens without changing application code, and the traffic policy is managed at the edge.
In banking and government systems, the action node inside an XML envelope can drive dispatch to different service groups. The legacy service contract stays intact while traffic decisions become content-aware.
Engineering teams can steer queries and mutations to separate sources based on the operationName field. Read-heavy and write-heavy operations land on dedicated backend groups.
For critical applications, role and tenant claims inside the JWT payload can be enforced at the edge. Requests missing required claims never reach the backend; requests with valid claims are placed under the appropriate traffic policy.
Content-aware routing and security across JSON, XML, multipart and JWT fields. Let's walk through a live setup on your own services.