Im modernen API-Verkehr liegen die eigentlichen Entscheidungsdaten im Body — nicht in den Headern.
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.
Unser Ansatz
TR7 behandelt Inhaltsbewusstsein nicht als separates Add-on. Es ist ein nativer Teil der Verkehrs- und Sicherheitsregelsprache.
Body-Parser-Funktionen sind direkt in die FX-Ausdruckssprache eingebaut
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-Parser laufen innerhalb der Runtime
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.
Dieselbe DSL steuert Verkehrsmanagement und WAAP-Scoring
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.
ADC- und WAAP-Modi folgen unterschiedlichen Integritätsregeln
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.
Fähigkeiten
Inhaltsbewusste Regeln wandeln strukturierte Payload-Daten in lesbare Bedingungen und durchsetzbare Aktionen um.
JSONPath-Abfragen schreiben Regeln direkt gegen API-Body-Felder
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.
XML-XPath-Prüfungen machen SOAP- und Unternehmensdienstverkehr transparent
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.
FIX-Nachrichtentyp und MQTT-Topic als Regelbedingungen
Eine Regel muss nicht bei HTTP enden. FIX-Nachrichtentyp und -Tag, MQTT-Topic und Paketstruktur stehen im selben Regel-Builder als Bedingungen zur Verfügung: Eine fehlerhafte Ordernachricht oder ein unerwartetes Topic wird auf der Delivery-Ebene abgefangen — bevor sie die Matching Engine oder den Broker erreicht. Handels- und IoT-Verkehr wird sonst als opakes TCP bewegt und gehofft; hier wird er gelesen, und die lesende Regel sieht genauso aus wie die Regeln, die Ihr Team ohnehin schreibt.
Formular- und Multipart-Felder binden Mandanten-, Datei- und Transaktionsentscheidungen
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.
JWT-Header- und Payload-Werte werden mit einer einzigen Funktion abgefragt
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- und List-Lookups skalieren Regeln über große Datensätze
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-Größen-, Tiefen- und Feldanzahl-Limits begrenzen das Parsing bevor es beginnt
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.
Allowed- und Must-Args bauen ein positives Sicherheitsmodell auf
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.
Response-Body-Rewrite ermöglicht Maskierung und Transformation im ADC-Modus
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.
Operative Tiefe
Inhaltsbewusstsein ist nicht nur Regelsyntax — es umfasst auch Puffer-Management, Parse-Caching, Audit-Transparenz und Edge-Case-Verhalten.
Body-Puffer-Management
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.
Parse-Ergebnis-Caching
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.
WAAP-Integritätsmodell
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.
Verhalten bei Chunked-Anfragen
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-Transparenz
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.
Audit- und SIEM-Trail
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.
Wann zu verwenden
Routing nach Mandantenwert innerhalb von JSON
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.
Unternehmensdienste nach SOAP-Aktion dispatchen
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.
GraphQL-Verkehr nach Operationstyp aufteilen
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.
Zugriffsentscheidungen auf JWT-Claims durchsetzen
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.
Häufig gestellte Fragen
Welche Content-Typen unterstützen die Body-Parser?
Kann dieselbe Regel sowohl ADC-Verkehr als auch WAAP-Richtlinien steuern?
Was ist der Integritätsunterschied zwischen ADC-Modus und WAAP-Modus?
Wie werden JWT-Inhalte in Regelausdrücken verwendet?
Wie geht das System mit sehr großen oder tief verschachtelten Bodies um?
Wenn mehrere Regeln dasselbe Body-Feld lesen, läuft das Parsing mehr als einmal?
API-Entscheidungen auf Basis des Body — nicht des Headers
Inhaltsbewusstes Routing und Sicherheit über JSON-, XML-, Multipart- und JWT-Felder. Lassen Sie uns ein Live-Setup auf Ihren eigenen Diensten durchgehen.