In modern API traffic, the real decision data lives in the body — not in the headers.
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.
Our approach
TR7 does not treat content awareness as a separate add-on. It is a native part of the traffic and security rule language.
Body parser functions are built directly into the FX expression 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 parsers run inside the runtime
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.
The same DSL drives traffic management and WAAP scoring
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.
ADC and WAAP modes follow different integrity 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.
Capabilities
Content-Aware Rules turn structured payload data into readable conditions and enforceable actions.
JSONPath queries write rules directly against API body fields
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.
XML XPath checks make SOAP and enterprise service traffic transparent
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.
FIX message type and MQTT topic as rule conditions
A rule does not have to stop at HTTP. FIX message type and tag, MQTT topic and packet structure are available as conditions in the same rule builder, so a malformed order message or an unexpected topic is caught at the delivery layer — before it reaches the matching engine or the broker. Trading and IoT traffic is usually moved as opaque TCP and hoped for; here it is read, and the rule that reads it looks exactly like the rules your team already writes.
Form and multipart fields bind tenant, file and transaction decisions
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.
JWT header and payload values are queried with a single function
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 and list lookups scale rules across large data sets
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, depth and field count limits gate parsing before it begins
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.
Allowed and Must Args build a positive security model
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.
Response body rewrite enables masking and transformation in ADC mode
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.
Operational depth
Content awareness is not just rule syntax — it also covers buffer management, parse caching, audit visibility and edge-case behavior.
Body buffer management
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.
Parse result caching
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.
WAAP integrity model
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.
Chunked request behavior
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 visibility
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.
Audit and SIEM trail
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.
When to use it
Route by tenant value inside JSON
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.
Dispatch enterprise services by SOAP action
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.
Split GraphQL traffic by operation type
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.
Enforce access decisions on JWT claims
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.
Frequently asked questions
Which content types do the body parsers support?
Can the same rule drive both ADC traffic and WAAP policy?
What is the integrity difference between ADC mode and WAAP mode?
How are JWT contents used in rule expressions?
How does the system handle very large or deeply nested bodies?
If multiple rules read the same body field, does parsing run more than once?
Make API decisions on the body — not the header
Content-aware routing and security across JSON, XML, multipart and JWT fields. Let's walk through a live setup on your own services.