La gestión de tráfico tradicional en la Capa 7 típicamente decide en función de la URL, el método, los headers y la dirección de origen. Ese modelo suele ser suficiente para las aplicaciones web clásicas, pero en las arquitecturas modernas de API la distinción crítica suele estar en campos dentro del cuerpo de la solicitud. La identidad del tenant, el rol del usuario, el tipo de transacción, el nombre del servicio o los metadatos de carga de archivos no están en los headers — están en los payloads JSON, XML, formulario o multipart.
Sin esa visibilidad, los operadores se ven empujados hacia opciones deficientes. O se coloca un gateway de API adicional frente a la gestión de tráfico — añadiendo un nuevo salto, una nueva licencia y una nueva carga operacional — o la aplicación misma se modifica para elevar el valor de decisión a los headers. Para backends heredados y críticos para el negocio, ese cambio a menudo no es factible.
Limitar la inspección del cuerpo solo a seguridad tampoco resuelve el problema. Si el WAAP puede leer el contenido pero el motor de enrutamiento no puede usar el mismo valor, la política de seguridad y la política de tráfico acaban en dos mundos separados. El resultado es lógica duplicada, reglas inconsistentes y mayor probabilidad de error.
El modelo correcto es hacer que las capacidades del parser del cuerpo sean una parte nativa del lenguaje de reglas. JSONPath, XPath, parámetros de formulario, claims JWT, regex y comprobaciones de map/list deben vivir en el mismo árbol de expresiones, y una única expresión debe dirigir tanto una acción de tráfico como un score WAAP.
TR7 Reglas Conscientes del Contenido cierran esta brecha: los campos dentro del cuerpo dejan de ser meramente datos inspeccionados y se convierten en señales que dirigen directamente la decisión.
TR7 no trata la conciencia del contenido como un complemento separado. Es una parte nativa del lenguaje de reglas de tráfico y seguridad.
JSONQUERY, XMLQUERY, XMLPATHEXISTS, PARAM, JWTHEADER y JWTPAYLOAD son funciones de primera clase en el lenguaje de reglas. Los operadores convierten el contenido del cuerpo en condiciones sin escribir código personalizado y vinculan esas condiciones directamente a acciones de tráfico o seguridad.
Los payloads JSON, XML y multipart se analizan en tiempo de ejecución y se exponen al motor de reglas como valores legibles. Los operadores deciden sobre campos significativos en lugar de ejecutar regex torpes sobre cada byte de la solicitud.
En TR7, una expresión escrita contra un campo del cuerpo puede dirigir el enrutamiento, la manipulación de headers y el scoring de firmas WAAP por igual. Este modelo compartido reduce la lógica duplicada entre las reglas de tráfico y las reglas de seguridad.
En modo ADC el cuerpo puede leerse y, en escenarios adecuados, reescribirse en el lado de la respuesta. En modo WAAP el cuerpo nunca se modifica — se lee, se puntúa y se bloquea cuando se supera el umbral de política.
Las Reglas Conscientes del Contenido convierten los datos de payload estructurados en condiciones legibles y acciones ejecutables.
La función JSONQUERY evalúa los campos del cuerpo JSON usando semántica JSONPath estándar. Los operadores pueden usar valores como `$.user.role`, `$.items[0].sku` o `$.tenant_id` como condiciones y vincularlos al enrutamiento del vService, a la manipulación de headers o al scoring WAAP. El tráfico de API ya no se dirige solo por endpoint — se dirige por el significado de negocio real de la solicitud.
XMLQUERY, XMLPATHTYPE y XMLPATHEXISTS ejecutan consultas XPath contra cuerpos XML. El nombre del servicio, el nodo de acción o el campo de operación dentro de un sobre SOAP puede dirigir las decisiones de enrutamiento y seguridad. Esto es particularmente valioso para aplicar dispatch a nivel de servicio y política sin modificar los backends heredados. Los payloads XML se convierten en datos estructurados dentro del motor de reglas, reduciendo la dependencia de regex frágiles.
La función PARAM convierte las cadenas de consulta, los cuerpos form-encoded y los campos de formulario en condiciones de regla. El parser multipart expone los metadatos de carga de archivos — nombre de campo, tipo de contenido y tamaño — a la política. Este patrón es útil para portales SaaS, flujos de carga de documentos y lógica de transacciones específica del usuario. El tráfico puede enrutarse o bloquearse según el contexto de negocio que porta el formulario.
JWTHEADER y JWTPAYLOAD exponen los campos de header y payload del token como valores consultables por JSONPath. El rol del usuario, el tenant, el nivel de autorización o los claims personalizados se convierten en entradas para las decisiones de tráfico y seguridad. Un claim requerido puede hacerse cumplir en el edge, los claims faltantes pueden fallar la solicitud, y el tráfico basado en roles puede dirigirse a grupos de backend dedicados — todo sin incluir la lógica de acceso en el código de la aplicación.
MAP_STR, MAP_REG, MAP_SUB, MAP_IP, MAP_BEG y MAP_END proporcionan búsquedas rápidas contra grandes conjuntos de valores. LIST_STR, LIST_REG, LIST_SUB, LIST_IP, LIST_BEG y LIST_END ofrecen el mismo modelo para comprobaciones basadas en listas. Los listados de tenants, los nombres de servicios permitidos, los rangos IP y los grupos de patrones pueden gestionarse de forma centralizada en lugar de como condiciones individuales, manteniendo los conjuntos de reglas grandes manejables.
BODY_SIZE, JSON_DEPTH, XML_DEPTH, JSON_KEY_COUNT y XML_NODE_COUNT definen límites protectores antes de que el parser entre en acción. Los payloads sobredimensionados, profundamente anidados o inflados se rechazan antes de que lleguen al backend. JSON_DEPTH tiene un valor predeterminado de 32 y es ajustable a nivel de política. El mismo control rige tanto el consumo de recursos como el abuso a nivel de parser.
JSON_MUST_ARGS, JSON_ALLOWED_ARGS, FORM_MUST_ARGS y FORM_ALLOWED_ARGS verifican que los campos esperados están presentes y que los campos inesperados están ausentes. En lugar de solo buscar patrones malos, el modelo declara la forma de una solicitud aceptable. Los campos requeridos faltantes o los parámetros inesperados pueden rechazarse por política. Este enfoque consciente del contrato es especialmente valioso en endpoints de transacciones críticas.
En modo ADC, la acción modifyResponse aplica sustitución basada en regex a los cuerpos de respuesta. Se usa para enmascarar datos personales, reescribir enlaces o adaptar direcciones internas para consumidores externos. El modo WAAP nunca modifica el cuerpo — solo lo lee y puntúa. Esta separación equilibra la flexibilidad de tráfico con la integridad de seguridad en la misma plataforma.
La conciencia del contenido no es solo sintaxis de reglas — también cubre la gestión de buffer, el almacenamiento en caché del parsing, la visibilidad de auditoría y el comportamiento en casos extremos.
El contenido del cuerpo se almacena en buffer antes del parsing, y el parser JSON, XML o multipart relevante luego se ejecuta sobre ese buffer. El buffer de cuerpo predeterminado es 16 KB; los parámetros del sistema pueden aumentarse para payloads JSON o XML más grandes. Cuando se supera el límite, la solicitud se rechaza con 413 para que el backend no se cargue con payloads sobredimensionados.
Los resultados de JSONPath y XPath leídos dentro de la misma solicitud se almacenan en caché en el espacio de variables con alcance de transacción. Una vez que una regla lee un campo del cuerpo, las reglas posteriores no vuelven a ejecutar el parser para el mismo campo. Esto reduce la latencia y el coste de procesamiento en cadenas de reglas largas.
En modo WAAP el cuerpo se lee pero nunca se modifica. El contenido alimenta las firmas, el scoring y la lógica de umbral; una vez que se supera el umbral la solicitud se bloquea. La capa de seguridad puede actuar sobre señales conscientes del contenido mientras preserva la integridad de la solicitud de extremo a extremo.
El parsing de solicitudes POST chunked comienza después de que se completa el reensamblado de chunks, de modo que los campos del cuerpo se evalúan como un payload completo y coherente. El tráfico chunked puede incurrir en una pequeña latencia adicional, pero el backend está protegido de flujos de payload parciales y no controlados.
GraphQL se gestiona actualmente a través de JSONPath: campos como el nombre de operación y la lista de campos dentro del cuerpo pueden usarse en condiciones de regla. Esto permite decisiones prácticas en el edge como separar las mutations de las queries. La validación de schema profundo está fuera del alcance de esta capacidad.
Qué regla leyó qué campo del cuerpo se registra en el log de auditoría. Los equipos de operaciones pueden rastrear por qué una solicitud específica fue enrutada, rechazada o puntuada en su SIEM. Esta trazabilidad evita que las reglas conscientes del contenido se comporten como una caja negra.
Los equipos SaaS pueden despachar tráfico a pools de backend separados basándose en el campo tenant_id dentro del cuerpo JSON. La separación por tenant ocurre sin cambiar el código de la aplicación, y la política de tráfico se gestiona en el edge.
En sistemas bancarios y gubernamentales, el nodo de acción dentro de un sobre XML puede dirigir el dispatch a diferentes grupos de servicio. El contrato de servicio heredado se mantiene intacto mientras las decisiones de tráfico se vuelven conscientes del contenido.
Los equipos de ingeniería pueden dirigir las queries y las mutations a fuentes separadas basándose en el campo operationName. Las operaciones con muchas lecturas y las operaciones con muchas escrituras van a grupos de backend dedicados.
Para aplicaciones críticas, los claims de rol y tenant dentro del payload JWT pueden hacerse cumplir en el edge. Las solicitudes sin claims requeridos nunca llegan al backend; las solicitudes con claims válidos se colocan bajo la política de tráfico apropiada.
Enrutamiento consciente del contenido y seguridad a través de campos JSON, XML, multipart y JWT. Permítanos guiarle por una configuración en vivo sobre sus propios servicios.