Herkömmliches Layer-7-Verkehrsmanagement entscheidet typischerweise anhand von URL, Methode, Headern und Quelladresse. Dieses Modell ist für klassische Webanwendungen oft ausreichend, aber in modernen API-Architekturen liegt die entscheidende Unterscheidung meist in Feldern im Anfrage-Body. Mandantenidentität, Benutzerrolle, Transaktionstyp, Dienstname oder Dateiupload-Metadaten befinden sich nicht in Headern — sie stecken in JSON-, XML-, Formular- oder Multipart-Payloads.
Ohne diese Transparenz werden Operatoren zu schlechten Optionen gedrängt. Entweder wird ein zusätzliches API-Gateway vor das Verkehrsmanagement gestellt — was einen neuen Hop, neue Lizenz und neue operative Belastung hinzufügt — oder die Anwendung selbst wird geändert, um den Entscheidungswert in Header zu heben. Bei Legacy- und geschäftskritischen Backends ist diese Änderung oft nicht durchführbar.
Die Body-Inspektion auf Sicherheit allein zu beschränken löst das Problem ebenfalls nicht. Wenn der WAAP den Inhalt lesen kann, aber die Routing-Engine denselben Wert nicht verwenden kann, leben Sicherheitsrichtlinie und Verkehrsrichtlinie in zwei separaten Welten. Das Ergebnis ist duplizierte Logik, inkonsistente Regeln und eine erhöhte Fehlerwahrscheinlichkeit.
Das richtige Modell besteht darin, Body-Parser-Fähigkeiten zu einem nativen Teil der Regelsprache zu machen. JSONPath, XPath, Formularparameter, JWT-Claims, Regex und Map/List-Prüfungen sollten im selben Ausdrucksbaum existieren, und ein einzelner Ausdruck sollte sowohl eine Verkehrsaktion als auch einen WAAP-Score steuern.
TR7 Inhaltsbewusste Regeln schließen diese Lücke: Felder im Body hören auf, lediglich inspizierte Daten zu sein, und werden zu Signalen, die die Entscheidung direkt steuern.
TR7 behandelt Inhaltsbewusstsein nicht als separates Add-on. Es ist ein nativer Teil der Verkehrs- und Sicherheitsregelsprache.
JSONQUERY, XMLQUERY, XMLPATHEXISTS, PARAM, JWTHEADER und JWTPAYLOAD sind erstklassige Funktionen in der Regelsprache. Operatoren wandeln Body-Inhalte in Bedingungen um, ohne benutzerdefinierten Code zu schreiben, und binden diese Bedingungen direkt an Verkehrs- oder Sicherheitsaktionen.
JSON-, XML- und Multipart-Payloads werden zur Laufzeit geparst und der Regel-Engine als lesbare Werte zur Verfügung gestellt. Operatoren entscheiden anhand bedeutungsvoller Felder, anstatt grobe Regex über jedes Byte der Anfrage laufen zu lassen.
In TR7 kann ein gegen ein Body-Feld geschriebener Ausdruck gleichermaßen Routing, Header-Manipulation und WAAP-Signatur-Scoring steuern. Dieses gemeinsame Modell reduziert duplizierte Logik zwischen Verkehrsregeln und Sicherheitsregeln.
Im ADC-Modus kann der Body gelesen und in geeigneten Szenarien auf der Response-Seite neu geschrieben werden. Im WAAP-Modus wird der Body niemals modifiziert — er wird gelesen, bewertet und die Anfrage wird blockiert, wenn der Richtlinienschwellenwert überschritten wird.
Inhaltsbewusste Regeln wandeln strukturierte Payload-Daten in lesbare Bedingungen und durchsetzbare Aktionen um.
Die JSONQUERY-Funktion wertet JSON-Body-Felder mit Standard-JSONPath-Semantik aus. Operatoren können Werte wie `$.user.role`, `$.items[0].sku` oder `$.tenant_id` als Bedingungen verwenden und sie an vService-Routing, Header-Manipulation oder WAAP-Scoring binden. API-Verkehr wird nicht mehr nur nach Endpunkt gesteuert — er wird durch die tatsächliche Geschäftsbedeutung der Anfrage gesteuert.
XMLQUERY, XMLPATHTYPE und XMLPATHEXISTS führen XPath-Abfragen gegen XML-Bodies aus. Der Dienstname, der Aktionsknoten oder das Operationsfeld innerhalb eines SOAP-Envelopes können Routing- und Sicherheitsentscheidungen steuern. Dies ist besonders wertvoll für die Anwendung von Dispatch- und Richtlinien auf Dienstebene ohne Änderung von Legacy-Backends. XML-Payloads werden zu strukturierten Daten innerhalb der Regel-Engine, was die Abhängigkeit von fehleranfälligem Regex reduziert.
Die PARAM-Funktion wandelt Query-Strings, formularcodierte Bodies und Formularfelder in Regelbedingungen um. Der Multipart-Parser stellt Dateiupload-Metadaten — Feldname, Content-Type und Größe — der Richtlinie zur Verfügung. Dieses Muster ist nützlich für SaaS-Portale, Dokumentenupload-Abläufe und benutzerspezifische Transaktionslogik. Verkehr kann basierend auf dem Geschäftskontext, den das Formular trägt, geroutet oder blockiert werden.
JWTHEADER und JWTPAYLOAD machen Token-Header- und Payload-Felder als JSONPath-abfragbare Werte zugänglich. Benutzerrolle, Mandant, Autorisierungslevel oder benutzerdefinierte Claims werden zu Inputs für Verkehrs- und Sicherheitsentscheidungen. Ein erforderlicher Claim kann am Edge durchgesetzt werden, fehlende Claims können die Anfrage ablehnen, und rollenbasierter Verkehr kann zu dedizierten Backend-Gruppen gesteuert werden — alles ohne Zugangslogik in den Anwendungscode einzubetten.
MAP_STR, MAP_REG, MAP_SUB, MAP_IP, MAP_BEG und MAP_END bieten schnelle Lookups gegen große Wertesets. LIST_STR, LIST_REG, LIST_SUB, LIST_IP, LIST_BEG und LIST_END bieten dasselbe Modell für listenbasierte Prüfungen. Mandantenlisten, erlaubte Dienstnamen, IP-Bereiche und Mustergruppen können zentral verwaltet werden, anstatt als Einzelbedingungen, wodurch große Regelsets wartbar bleiben.
BODY_SIZE, JSON_DEPTH, XML_DEPTH, JSON_KEY_COUNT und XML_NODE_COUNT definieren Schutzlimits bevor der Parser startet. Zu große, tief verschachtelte oder aufgeblähte Payloads werden abgelehnt, bevor sie das Backend erreichen. JSON_DEPTH ist standardmäßig 32 und auf Richtlinienebene anpassbar. Dieselbe Steuerung regelt sowohl Ressourcenverbrauch als auch Parser-Level-Missbrauch.
JSON_MUST_ARGS, JSON_ALLOWED_ARGS, FORM_MUST_ARGS und FORM_ALLOWED_ARGS prüfen, ob erwartete Felder vorhanden und unerwartete Felder abwesend sind. Anstatt nur nach schlechten Mustern zu suchen, deklariert das Modell die Form einer akzeptablen Anfrage. Fehlende erforderliche Felder oder unerwartete Parameter können pro Richtlinie abgelehnt werden. Dieser vertragsnahe Ansatz ist besonders wertvoll bei kritischen Transaktionsendpunkten.
Im ADC-Modus wendet die modifyResponse-Aktion Regex-basierte Substitution auf Response-Bodies an. Sie wird für die Maskierung personenbezogener Daten, das Umschreiben von Links oder die Anpassung interner Adressen für externe Verbraucher verwendet. Der WAAP-Modus modifiziert den Body niemals — er liest und bewertet ihn nur. Diese Trennung balanciert Verkehrsflexibilität mit Sicherheitsintegrität auf derselben Plattform.
Inhaltsbewusstsein ist nicht nur Regelsyntax — es umfasst auch Puffer-Management, Parse-Caching, Audit-Transparenz und Edge-Case-Verhalten.
Body-Inhalt wird vor dem Parsing gepuffert, und der relevante JSON-, XML- oder Multipart-Parser läuft dann auf diesem Puffer. Der Standard-Body-Puffer beträgt 16 KB; Systemparameter können für größere JSON- oder XML-Payloads erhöht werden. Wenn das Limit überschritten wird, wird die Anfrage mit 413 abgelehnt, sodass das Backend nicht mit überdimensionierten Payloads belastet wird.
JSONPath- und XPath-Ergebnisse, die innerhalb derselben Anfrage gelesen werden, werden im transaktionsbezogenen Variablenbereich zwischengespeichert. Sobald eine Regel ein Body-Feld gelesen hat, führen nachfolgende Regeln den Parser für dasselbe Feld nicht erneut aus. Dies reduziert Latenz und Verarbeitungskosten in langen Regelketten.
Im WAAP-Modus wird der Body gelesen, aber niemals modifiziert. Der Inhalt speist Signaturen, Scoring und die Schwellenwertlogik; sobald der Schwellenwert überschritten wird, wird die Anfrage blockiert. Die Sicherheitsschicht kann auf inhaltsbewusste Signale reagieren und dabei die Anfrageintegrität durchgehend wahren.
Das Parsing von Chunked-POST-Anfragen beginnt nach der Chunk-Reassemblierung, sodass Body-Felder als vollständige, kohärente Payload ausgewertet werden. Chunked-Verkehr kann eine geringe zusätzliche Latenz verursachen, aber das Backend ist vor partiellen und unkontrollierten Payload-Streams geschützt.
GraphQL wird derzeit über JSONPath behandelt: Felder wie Operationsname und Feldliste innerhalb des Body können in Regelbedingungen verwendet werden. Dies ermöglicht praktische Edge-Entscheidungen wie die Trennung von Mutations und Queries. Tiefe Schema-Validierung liegt außerhalb des Anwendungsbereichs dieser Fähigkeit.
Welche Regel welches Body-Feld gelesen hat, wird im Audit-Log erfasst. Betriebsteams können in ihrem SIEM nachverfolgen, warum eine bestimmte Anfrage geroutet, abgelehnt oder bewertet wurde. Diese Nachverfolgbarkeit verhindert, dass inhaltsbewusste Regeln wie eine Black Box agieren.
SaaS-Teams können Verkehr basierend auf dem tenant_id-Feld im JSON-Body an separate Backend-Pools weiterleiten. Mandantentrennung erfolgt ohne Änderung des Anwendungscodes, und die Verkehrsrichtlinie wird am Edge verwaltet.
In Banking- und Behördensystemen kann der Aktionsknoten in einem XML-Envelope den Dispatch zu verschiedenen Dienstgruppen steuern. Der Legacy-Servicevertrag bleibt intakt, während Verkehrsentscheidungen inhaltsbewusst werden.
Engineering-Teams können Queries und Mutations basierend auf dem operationName-Feld zu separaten Quellen steuern. Leselastige und schreiblastige Operationen landen in dedizierten Backend-Gruppen.
Bei kritischen Anwendungen können Rollen- und Mandanten-Claims innerhalb der JWT-Payload am Edge durchgesetzt werden. Anfragen ohne erforderliche Claims erreichen das Backend nicht; Anfragen mit gültigen Claims werden unter die entsprechende Verkehrsrichtlinie gestellt.
Inhaltsbewusstes Routing und Sicherheit über JSON-, XML-, Multipart- und JWT-Felder. Lassen Sie uns ein Live-Setup auf Ihren eigenen Diensten durchgehen.