O gerenciamento tradicional de tráfego de Camada 7 geralmente decide com base em URL, método, headers e endereço de origem. Esse modelo frequentemente é suficiente para aplicações web clássicas, mas em arquiteturas de API modernas a distinção crítica geralmente está em campos dentro do corpo da requisição. Identidade de tenant, papel de usuário, tipo de transação, nome do serviço ou metadados de upload de arquivo não estão nos headers — estão em payloads JSON, XML, de formulário ou multipart.
Sem essa visibilidade, os operadores são empurrados para opções ruins. Ou um gateway de API adicional é colocado à frente do gerenciamento de tráfego — adicionando um novo salto, nova licença e novo ônus operacional — ou a própria aplicação é alterada para elevar o valor de decisão para os headers. Para backends legados e críticos para o negócio, essa mudança frequentemente não é viável.
Limitar a inspeção de corpo apenas à segurança também não resolve o problema. Se o WAAP consegue ler o conteúdo, mas o mecanismo de roteamento não consegue usar o mesmo valor, a política de segurança e a política de tráfego acabam em dois mundos separados. O resultado é lógica duplicada, regras inconsistentes e maior chance de erro.
O modelo correto é tornar as capacidades do parser de corpo uma parte nativa da linguagem de regras. JSONPath, XPath, parâmetros de formulário, claims JWT, regex e verificações de mapa/lista devem viver na mesma árvore de expressões, e uma única expressão deve conduzir tanto uma ação de tráfego quanto uma pontuação WAAP.
As Regras Conscientes de Conteúdo do TR7 fecham essa lacuna: campos dentro do corpo deixam de ser apenas dados inspecionados e se tornam sinais que conduzem diretamente a decisão.
O TR7 não trata a consciência de conteúdo como um complemento separado. É uma parte nativa da linguagem de regras de tráfego e segurança.
JSONQUERY, XMLQUERY, XMLPATHEXISTS, PARAM, JWTHEADER e JWTPAYLOAD são funções de primeira classe na linguagem de regras. Os operadores transformam conteúdo do corpo em condições sem escrever código personalizado e vinculam essas condições diretamente a ações de tráfego ou segurança.
Payloads JSON, XML e multipart são analisados em runtime e expostos ao mecanismo de regras como valores legíveis. Os operadores decidem com base em campos significativos em vez de executar regex bruto sobre cada byte da requisição.
No TR7, uma expressão escrita contra um campo de corpo pode conduzir roteamento, manipulação de headers e pontuação de assinatura WAAP igualmente. Esse modelo compartilhado reduz a lógica duplicada entre regras de tráfego e regras de segurança.
No modo ADC, o corpo pode ser lido e, em cenários adequados, reescrito no lado da resposta. No modo WAAP, o corpo nunca é modificado — é lido, pontuado e bloqueado quando o limite de política é excedido.
As Regras Conscientes de Conteúdo transformam dados de payload estruturado em condições legíveis e ações executáveis.
A função JSONQUERY avalia campos de corpo JSON usando semântica JSONPath padrão. Os operadores podem usar valores como `$.user.role`, `$.items[0].sku` ou `$.tenant_id` como condições e vinculá-los ao roteamento de vService, manipulação de headers ou pontuação WAAP. O tráfego de API não é mais direcionado apenas pelo endpoint — é direcionado pelo significado de negócio real da requisição.
XMLQUERY, XMLPATHTYPE e XMLPATHEXISTS executam consultas XPath contra corpos XML. O nome do serviço, o nó de ação ou o campo de operação dentro de um envelope SOAP podem conduzir decisões de roteamento e segurança. Isso é particularmente valioso para aplicar despacho e política no nível de serviço sem modificar backends legados. Payloads XML se tornam dados estruturados dentro do mecanismo de regras, reduzindo a dependência de regex frágil.
A função PARAM transforma query strings, corpos codificados em formulário e campos de formulário em condições de regras. O parser multipart expõe metadados de upload de arquivo — nome do campo, tipo de conteúdo e tamanho — à política. Esse padrão é útil para portais SaaS, fluxos de upload de documentos e lógica de transação específica de usuário. O tráfego pode ser roteado ou bloqueado com base no contexto de negócio que o formulário carrega.
JWTHEADER e JWTPAYLOAD expõem os campos de header e payload do token como valores consultáveis por JSONPath. Papel de usuário, tenant, nível de autorização ou claims personalizados se tornam entradas para decisões de tráfego e segurança. Um claim obrigatório pode ser aplicado na borda, claims ausentes podem reprovar a requisição, e o tráfego baseado em papel pode ser direcionado para grupos de backend dedicados — tudo sem incorporar lógica de acesso no código da aplicação.
MAP_STR, MAP_REG, MAP_SUB, MAP_IP, MAP_BEG e MAP_END fornecem lookups rápidos contra grandes conjuntos de valores. LIST_STR, LIST_REG, LIST_SUB, LIST_IP, LIST_BEG e LIST_END oferecem o mesmo modelo para verificações baseadas em listas. Listas de tenants, nomes de serviços permitidos, intervalos de IP e grupos de padrões podem ser gerenciados centralmente em vez de como condições únicas, mantendo grandes conjuntos de regras gerenciáveis.
BODY_SIZE, JSON_DEPTH, XML_DEPTH, JSON_KEY_COUNT e XML_NODE_COUNT definem limites de proteção antes de o parser atuar. Payloads superdimensionados, profundamente aninhados ou inflados são rejeitados antes de chegarem ao backend. JSON_DEPTH tem padrão 32 e é ajustável no nível de política. O mesmo controle governa tanto o consumo de recursos quanto o abuso no nível do parser.
JSON_MUST_ARGS, JSON_ALLOWED_ARGS, FORM_MUST_ARGS e FORM_ALLOWED_ARGS verificam se campos esperados estão presentes e se campos inesperados estão ausentes. Em vez de apenas buscar padrões ruins, o modelo declara a forma de uma requisição aceitável. Campos obrigatórios ausentes ou parâmetros inesperados podem ser rejeitados por política. Essa abordagem orientada a contrato é especialmente valiosa em endpoints transacionais críticos.
No modo ADC, a ação modifyResponse aplica substituição baseada em regex a corpos de resposta. É usada para mascarar dados pessoais, reescrever links ou adaptar endereços internos para consumidores externos. O modo WAAP nunca modifica o corpo — apenas lê e pontua. Essa separação equilibra flexibilidade de tráfego com integridade de segurança na mesma plataforma.
A consciência de conteúdo não é apenas sintaxe de regras — também abrange gerenciamento de buffer, cache de análise, visibilidade de auditoria e comportamento em casos extremos.
O conteúdo do corpo é armazenado em buffer antes da análise, e o parser JSON, XML ou multipart relevante então processa esse buffer. O buffer de corpo padrão é de 16 KB; parâmetros do sistema podem ser aumentados para payloads JSON ou XML maiores. Quando o limite é excedido, a requisição é rejeitada com 413 para que o backend não seja sobrecarregado com payloads superdimensionados.
Os resultados de JSONPath e XPath lidos dentro da mesma requisição são armazenados em cache no espaço de variáveis com escopo de transação. Uma vez que uma regra lê um campo do corpo, as regras subsequentes não reexecutam o parser para o mesmo campo. Isso reduz a latência e o custo de processamento em longas cadeias de regras.
No modo WAAP, o corpo é lido mas nunca modificado. O conteúdo alimenta assinaturas, pontuação e lógica de limite; uma vez que o limite é excedido, a requisição é bloqueada. A camada de segurança pode agir sobre sinais conscientes de conteúdo enquanto preserva a integridade da requisição de ponta a ponta.
A análise de requisições POST em chunks começa após a remontagem dos chunks ser concluída, para que os campos do corpo sejam avaliados como um payload completo e coerente. O tráfego em chunks pode incorrer em uma pequena latência adicional, mas o backend fica protegido de streams de payload parciais e não controlados.
O GraphQL é atualmente tratado via JSONPath: campos como nome de operação e lista de campos dentro do corpo podem ser usados em condições de regras. Isso permite decisões práticas na borda, como separar mutations de queries. A validação profunda de schema está fora do escopo desta capacidade.
Qual regra leu qual campo do corpo é registrado no log de auditoria. As equipes de operações podem rastrear por que uma requisição específica foi roteada, rejeitada ou pontuada em seu SIEM. Essa rastreabilidade evita que as regras conscientes de conteúdo se comportem como uma caixa preta.
Equipes SaaS podem despachar tráfego para pools de backend separados com base no campo tenant_id dentro do corpo JSON. A separação de tenants acontece sem alterar o código da aplicação, e a política de tráfego é gerenciada na borda.
Em sistemas bancários e governamentais, o nó de ação dentro de um envelope XML pode conduzir o despacho para diferentes grupos de serviço. O contrato de serviço legado permanece intacto enquanto as decisões de tráfego se tornam conscientes de conteúdo.
Equipes de engenharia podem direcionar queries e mutations para origens separadas com base no campo operationName. Operações com leitura intensa e escrita intensa chegam a grupos de backend dedicados.
Para aplicações críticas, claims de papel e tenant dentro do payload JWT podem ser aplicados na borda. Requisições com claims obrigatórios ausentes nunca chegam ao backend; requisições com claims válidos são colocadas sob a política de tráfego apropriada.
Roteamento e segurança conscientes de conteúdo em campos JSON, XML, multipart e JWT. Vamos percorrer uma configuração ao vivo nos seus próprios serviços.