HTTP method override schlägt reine Methodenprüfung

Eine Prüfung nach HTTP-Methode ist unsicher, wenn sie nur die Request-Zeile betrachtet. Ein Request kann als POST ankommen, X-HTTP-Method-Override: DELETE enthalten und nach einer Umschreibung durch Middleware einen Lösch-Handler erreichen. Wenn Freigabeanzeige, Gateway-Regel, Autorisierung oder Audit ihn als gewöhnlichen POST einstufen, haben sie die Hülle geprüft und die Aktion übersehen.

Dieses Verhalten ist kein HTTP-Protokolltrick, den jeder Server versteht. Es ist eine Konvention der Anwendung und wird deshalb leicht übersehen. Die Unterstützung hängt von Framework, Middleware-Reihenfolge, Route und Deployment ab. Die richtige Antwort ist nicht, jeden POST als heimlich destruktiv zu behandeln. Man muss ermitteln, wo Overrides angenommen werden, sie vor jeder Sicherheitsentscheidung auflösen und Mehrdeutigkeit ablehnen.

Transportmethode und effektive Methode sind verschiedene Fakten

Ein Stack mit Override-Unterstützung muss zwei Methoden festhalten: die Methode in der HTTP-Request-Zeile und die Methode, nach der die Anwendung schließlich routet. Ich nenne sie Transportmethode und effektive Methode. Meist stimmen sie überein. Gefährlich wird es, wenn ein Vermittler die Transportmethode freigibt oder filtert, während eine spätere Komponente nach der effektiven Methode routet.

RFC 9110 bezeichnet das Methodentoken als wichtigste Quelle der Request-Semantik. POST fordert eine ressourcenspezifische Verarbeitung, DELETE die Entfernung der Verbindung zwischen Zielressource und ihrer aktuellen Funktion. Der RFC standardisiert X-HTTP-Method-Override nicht. Der Header gehört zu Kompatibilitätskonventionen für Clients oder Vermittler, die nur GET und POST verarbeiten konnten.

Gängige Software implementiert die Konvention weiterhin. Express-Middleware method-override liest bei POST standardmäßig X-HTTP-Method-Override. Nimmt sie einen Wert an, ändert sie req.method und bewahrt den vorigen Wert in req.originalMethod. ASP.NET Core bietet ebenfalls Override-Middleware mit diesem Standard-Header. Springs HiddenHttpMethodFilter geht anders vor: Er liest den Formularparameter _method bei POST und erlaubt PUT, DELETE und PATCH.

Diese Details schärfen eine oft verwischte Unterscheidung. „Das Gateway erlaubte POST“ beschreibt den Transport. „Die Anwendung führte DELETE aus“ beschreibt das Verhalten. Eine Freigabe oder Zugriffsentscheidung braucht die zweite Angabe. Kann die entscheidende Komponente die effektive Methode nicht ermitteln, muss sie Override-Signale ablehnen, statt still nach dem äußeren Verb zu klassifizieren.

Framework-Unterstützung allein beweist keine Angriffsfläche. Eine Express-Anwendung muss Middleware installieren und anordnen, ASP.NET Core muss sie hinzufügen und Spring den Filter aktivieren und platzieren. Die eingesetzte Konfiguration mit Reverse Proxys und routenspezifischer Middleware bestimmt das Ergebnis. Quellcode liefert Kandidaten, ein zustandsbewusster Test liefert Belege.

Ein freigegebener POST kann den DELETE-Handler erreichen

Ein getunnelter Schreibzugriff rutscht durch, wenn Komponenten nicht darin übereinstimmen, welche Darstellung der Aktion maßgeblich ist. Angenommen, ein Agent schlägt diesen Request an eine Projekt-API vor:

POST /v1/projects/42 HTTP/1.1
Host: api.example.test
Authorization: Bearer [injected outside the agent]
X-HTTP-Method-Override: DELETE
Content-Length: 0

Die Freigabeschicht zeigt „POST /v1/projects/42“ und wendet eine Regel an, die POST für die Sitzung erlaubt. Ein Reverse Proxy leitet den unbekannten Header weiter. RFC 9110 verlangt im Allgemeinen, dass Proxys unbekannte Felder weiterreichen, sofern die Konfiguration sie nicht blockiert oder transformiert. In der Anwendung ändert die Middleware die Methode vor dem Routing. Der Router wählt DELETE und das Projekt verschwindet.

Dieser Fehler benötigt keine mangelhafte DELETE-Autorisierung. Die Anwendung kann die Identität korrekt zum Löschen berechtigen. Der Defekt liegt früher: Ein Mensch oder Automat hat eine wesentlich andere Aktion freigegeben, weil sein Klassifikator eine unterstützte Eingabe ignorierte. Dieselbe Trennung kann Web Application Firewall, Rate Limit, CSRF-Kontrolle, Metriken und Zugriffsprotokolle betreffen.

Die Middleware-Reihenfolge bestimmt, welche Kontrolle welche Angabe sieht. Die Express-Dokumentation ist direkt: Der Override muss vor jeder Middleware laufen, die die Request-Methode kennen muss. Für Routing und CSRF innerhalb eines Prozesses stimmt das. Ein externes Gateway, das bereits anhand der Request-Zeile entschieden hat, wird dadurch nicht repariert.

Ein zweiter Fehler ist leiser. Das Edge-Protokoll schreibt POST, das Anwendungsprotokoll DELETE, und die Untersuchung behandelt beide als getrennte Requests. Eine gemeinsame Request-ID kann sie verbinden, aber nur wenn beide Seiten sie erhalten und das Team die Methodenfelder vergleicht. Ein einziger normalisierter Aktionsdatensatz ist weniger fehleranfällig.

Leiten Sie die Auswirkung nicht allein aus dem Wort DELETE ab. RFC 9110 erklärt, dass DELETE die Zuordnung einer Ressource zu ihrer aktuellen Funktion entfernt; Vernichtung und Speicherfreigabe hängen von der Anwendung ab. Ein DELETE-Endpunkt kann archivieren, deaktivieren, Arbeit einreihen oder Daten löschen. Prüfen Sie die konkrete Folge der Route, nicht die allgemeine Verbdefinition.

Testen Sie den Endpunkt mit einer kontrollierten Matrix

Ein verlässlicher Test vergleicht den resultierenden Zustand nach nativen Methoden, Override-Headern und Parameterkonventionen an einer Wegwerfressource. Führen Sie ihn in Staging oder gegen ein Fixture für destruktive Tests aus. Nutzen Sie eine Identität mit den Rechten des echten Aufrufers und erstellen Sie das Fixture vor jedem Fall neu, damit ein erfolgreiches Löschen das nächste Ergebnis nicht verfälscht.

Beginnen Sie mit einem POST ohne Override. Erfassen Sie Status, Response-Body und Zustand. Senden Sie danach einen nativen DELETE, um Route und Berechtigung zu bestätigen. Wiederholen Sie POST schließlich mit jeder Konvention. Eine minimale Header-Prüfung sieht so aus:

BASE='https://staging.example.test'
ID='override-probe-17'

curl -sS \n  -D response.headers \n  -o response.body \n  -w 'case=x-http-method-override outer=POST status=%{http_code} bytes=%{size_download}
' \n  -X POST "$BASE/v1/projects/$ID" \n  -H 'Authorization: Bearer test-token' \n  -H 'X-HTTP-Method-Override: DELETE'

curl -sS \n  -o state.body \n  -w 'verify=read-after-request status=%{http_code} bytes=%{size_download}
' \n  -H 'Authorization: Bearer test-token' \n  "$BASE/v1/projects/$ID"

Die Ausgabe besitzt absichtlich eine stabile, für CI lesbare Form:

case=x-http-method-override outer=POST status=204 bytes=0
verify=read-after-request status=404 bytes=71

Das Beispiel zeigt einen Override, der das Fixture löschte; die Statuswerte gelten nicht überall. Manche APIs antworten mit 200 und Dokument, mit 202 bei eingereihter Löschung oder mit einer weiterhin lesbaren Soft-Delete-Darstellung. Definieren Sie Erfolg nach dem Vertrag Ihrer Anwendung.

Nutzen Sie eine Matrix statt einer improvisierten Folge. Der Kontrollfall ist POST ohne Override und muss normales POST-Verhalten zeigen. Der native Fall ist DELETE ohne Override. Senden Sie dann POST mit X-HTTP-Method-Override: DELETE, X-HTTP-Method: DELETE und X-Method-Override: DELETE. Schließen Sie mit ?_method=DELETE im Query und _method=DELETE im Formular ab. Jeder Fall muss Ihrem bewussten Design entsprechen oder ohne Zustandsänderung scheitern.

Der OWASP Web Security Testing Guide nennt diese drei Header und empfiehlt Wiederholungen mit Overrides, wenn eine eingeschränkte Methode abgewiesen wird. Ein reiner Statusvergleich reicht mir nicht, denn Unterschiede können aus Validierung, Routing oder Vermittlern stammen. Prüfen Sie nach jedem Versuch Ressource, Version und eingereihte Aufgaben.

Wenn Sie den Stack kontrollieren, erfassen Sie jeden Hop: Edge-Log, Freigabeereignis, Anwendungslog, gewählte Route und Datenergebnis. Gesucht wird eine Abweichung. Sicher sind eine einheitliche Ablehnung oder eine bewusste Normalisierung mit derselben Autorisierung und Freigabe wie beim nativen DELETE.

Statuscodes sind Hinweise, Zustandsänderungen sind Beweise

Ein HTTP-Status zeigt allein nicht, ob der Override ausgeführt wurde. 204 gefolgt von einem fehlenden Fixture ist ein starker Beleg. 200 kann eine normale POST-Antwort, eine Löschbestätigung oder ein schlecht codierter Fehler sein. 405 kann vom Edge vor der Middleware stammen, während eine andere Route oder ein anderer Inhaltstyp sie weiterhin erreicht.

Bauen Sie die Assertion um eine Canary-Ressource mit eindeutiger ID und bekannter Anfangsversion. Lesen Sie sie vor dem Test und speichern Sie Versionsmarke oder Hash. Lesen Sie sie danach erneut und untersuchen Sie einen Operationsdatensatz. Wählen Sie für Updates ein harmloses, eindeutiges Feld. Klären Sie für Löschungen, ob sie hart, weich oder verzögert ablaufen.

Der Antwortvergleich hilft trotzdem. Speichern Sie Status, ausgewählte Header, Größe und Body-Hash. Vergleichen Sie den Override mit einfachem POST und nativem DELETE. Ähneln Antwort und Zustand DELETE, ist der Befund überzeugend. Sieht die Antwort nach POST aus, der Zustand aber nach DELETE, nutzt die Antwort- oder Logschicht womöglich die äußere Methode.

Weiterleitungen verdienen einen eigenen Test. Ein Client kann sein Verhalten bei 301, 302, 303, 307 oder 308 ändern, und Werkzeuge bewahren Methode und Body unterschiedlich. Deaktivieren Sie zuerst das Folgen und erfassen Sie Location. Folgen Sie danach bewusst jedem Hop. Mischen Sie Weiterleitung und Override nicht in einem undurchsichtigen Ergebnis.

Asynchrone APIs erfordern längere Beobachtung, keine Vermutung. Liefert die Antwort eine Operations-ID, fragen Sie sie nach Vertrag ab. Fehlt ein dauerhafter Verweis, prüfen Sie Queue oder Anwendungslog in Staging. Kennzeichnen Sie einen unklaren Fall als unklar, nicht als sicher.

Prüfen Sie auch den negativen Zustand. Ein abgelehnter Override darf nichts erstellen, ändern, archivieren, einreihen, mailen oder einen privilegierten Webhook auslösen. Ein sauberer 4xx kann täuschen, wenn eine spätere Komponente bereits einen Effekt festgeschrieben hat. Instrumentieren Sie das Fixture so, dass diese Reihenfolge sichtbar wird.

Header-Varianten und Mehrdeutigkeit gehören in denselben Test

Nur die kanonische Schreibweise zu testen übersieht Kompatibilitätscode und Parser-Unterschiede. Übliche Namen sind X-HTTP-Method-Override, X-HTTP-Method und X-Method-Override, doch Anwendungen können eigene Getter definieren. Query und Formulare können _method tragen, ältere Integrationen herstellerbezogene Namen.

Die Großschreibung des Namens ist keine eigene Konvention. RFC 9110 erklärt Feldnamen als unabhängig von Groß- und Kleinschreibung, daher bezeichnen x-http-method-override und X-HTTP-Method-Override dasselbe Feld. Ein Filter für nur eine Schreibweise ist defekt, auch wenn die Bibliothek Namen normalisiert.

Doppelte und widersprüchliche Werte zeigen ein schwierigeres Problem. RFC 9110 erlaubt bei geeigneten Feldern das Zusammenführen wiederholter Zeilen mit Kommas und mahnt auch bei erwarteten Einzelwerten zur Beachtung von Duplikaten. Override-Header besitzen keine gemeinsame standardisierte Regel. Express nimmt die erste Wiederholung, während mehrere Getter eine Rangfolge zwischen Namen schaffen können.

Fügen Sie x-http-method-override: DELETE hinzu und verlangen Sie dasselbe Ergebnis. Senden Sie zweimal DELETE und erwarten Sie ein dokumentiertes Ergebnis oder Ablehnung. Senden Sie PUT gefolgt von DELETE sowie verschiedene Werte in zwei Namen; lehnen Sie beide Konflikte ab. Lehnen Sie auch PUT, DELETE, natives PATCH mit DELETE ohne expliziten Vertrag und DELETE zusammen mit _method=PATCH ab.

Bleiben Sie nicht bei DELETE. Testen Sie PUT und PATCH, da Prüfungen Erstellen, Ersetzen, Teilaktualisierung und Löschen verschieden bewerten können. Ein nicht unterstütztes Token dient als Negativkontrolle. Vermeiden Sie TRACE und CONNECT ohne expliziten Umfang; sie lösen anderes Infrastrukturverhalten aus, ohne den Befund zu stärken.

Leerzeichen und Großschreibung des Werts können inkonsistente Normalisierung zeigen. Senden Sie delete, DELETE sofern möglich, und einen leeren Wert. Normalisieren Sie nur dokumentierte Formen, validieren Sie gegen eine ausdrückliche Menge und lehnen Sie alles andere ab. Den ersten lesbaren Wert zu wählen öffnet den Bypass nach einem Proxy-Update erneut.

Agenten-Requests machen den blinden Fleck leichter erreichbar

KI-Agenten erzeugen die Schwäche nicht, verschärfen aber unvollständige Prüfungen. Sie können beliebige Header bilden, Beispiele wiederverwenden und einen gescheiterten DELETE als POST-Tunnel erneut versuchen, ohne die Freigabegrenze zu verstehen. Ein Mensch vor einer kompakten Karte konzentriert sich wahrscheinlich auf das sichtbare Verb und den Pfad.

Behandeln Sie jeden vom Agenten erzeugten Bestandteil als nicht vertrauenswürdige Aktionseingabe, auch scheinbare Kompatibilitätsmetadaten. Credential-Injektion außerhalb des Modells senkt die Offenlegung, macht die Operation aber nicht harmlos. Pfad, Methode, Header, Query und Body gelangen gemeinsam in ein System, das sie gemeinsam interpretieren kann.

Werkzeugschemas können Mehrdeutigkeit vor Entstehung des Requests verringern. Ein generisches HTTP-Werkzeug mit freien Headern erlaubt Overrides. Ein routenspezifisches Löschwerkzeug kann die destruktive Aktion direkt benennen und Override-Felder weglassen. Es ist leichter zu prüfen, sofern keine versteckte Möglichkeit für Zusatz-Header bleibt.

Ist ein generisches Werkzeug nötig, analysieren Sie den Vorschlag vor der Anzeige. Parser und Ausführer müssen dasselbe Inventar und dieselbe Priorität nutzen. Frieren Sie die normalisierte Aktion nach Freigabe ein. Ändert ein Vermittler später Header, muss seine deterministische Transformation Teil der Prüfung sein oder eine neue Freigabe erfolgen.

Auch Wiederholungen zählen. POST ist nicht von Natur aus harmlos oder idempotent. RFC 9110 definiert ihn breit, und viele POST-Endpunkte ändern Daten ohne Override. Das Werkzeug darf einen Retry nicht allein wegen des äußeren POST als sicher ansehen und nicht jeden POST als destruktiv behandeln. Es braucht Routensemantik und effektive Methode.

Trennen Sie Test- und Produktionsidentitäten. Ein breites Credential lässt alle Sonden gelingen und verdeckt Autorisierungsunterschiede. Nutzen Sie die echte eingeschränkte Rolle, bestätigen Sie gleiche Entscheidungen für native und getunnelte Form und protokollieren Sie die Anzeige. Der Fehler ist belegt, wenn Vorschlag, Anzeige, Ausführung und Zustand eine Kette bilden.

Die früheste Kontrolle muss die effektive Aktion klassifizieren

Jede methodenbasierte Entscheidung muss nach einem einzigen Resolver laufen oder sämtliche Override-Eingaben ablehnen. Das gilt für Freigabe, Autorisierung, CSRF, Routen, Limits und Audit. Eigenständiges Parsen in jeder Kontrolle garantiert Abweichungen.

Stellen Sie die Auflösung ausdrücklich dar:

{
  "transport_method": "POST",
  "effective_method": "DELETE",
  "override_source": "header:x-http-method-override",
  "override_value": "DELETE",
  "target": "/v1/projects/42",
  "ambiguous": false
}

Der Resolver muss Header und Parameter inventarisieren, alle Werte sammeln und bei mehreren unterschiedlichen Kandidaten ablehnen. Er sollte Overrides nur von erlaubten äußeren Methoden, meist POST, annehmen. Er validiert gegen bewusst unterstützte Methoden und erzeugt einen unveränderlichen Datensatz für nachgelagerte Kontrollen.

Setzen Sie die Autorisierung danach und binden Sie sie an Route und effektive Methode. „Darf diese Identität hier POST?“ ist zu schwach, wenn POST ein Tunnel ist. Fragen Sie, ob sie DELETE auf dieser Ressource ausführen darf. Wenden Sie dieselbe Handler-Autorisierung auf native und getunnelte Form an.

Die Freigabeanzeige sollte zuerst die Folge und bei Abweichung beide Formen zeigen. DELETE /v1/projects/42 via POST override nennt Aktion und Transport. Den Header nur in einem aufklappbaren Rohdatenfeld zu zeigen zwingt den Prüfer, das Risiko unter Zeitdruck zu finden.

Kann ein Gateway die Regeln nicht nachbilden, bringen Sie ihm kein unvollständiges Teilset bei. Lehnen Sie bekannte Signale vor der Freigabe ab oder verschieben Sie die Freigabe hinter eine vertrauenswürdige Normalisierung. Ein Gateway mit einem Header vor einer Anwendung mit drei erzeugt falsche Abdeckung.

Trennen Sie Auflösung und Geschäftssemantik. Der Resolver bestimmt DELETE; die Route entscheidet, ob das Archivieren, Widerrufen, Trennen oder Löschen bedeutet. Folgenreiche Operationen brauchen routenbezogene Beschreibungen. Methodennormalisierung ist nötig, ein Verb beschreibt aber nicht jeden Effekt.

Einen Header zu entfernen reicht nicht

X-HTTP-Method-Override am Proxy zu entfernen ist nur sicher, wenn kein Client absichtlich tunnelt. Die Maßnahme ist beliebt, weil sie einfach ist und den ersten Nachweis blockiert. Sie scheitert, wenn ein anderer Header, _method, ein direkter Upstream-Pfad oder spätere Middleware aktiv bleibt.

Microsofts YARP-Leitfaden nennt alle drei Header, erklärt ihre standardmäßige Weiterleitung und empfiehlt bei gewünschter Sperre eine Entfernungstransformation. Das ist nützliche Härtung, beweist aber nicht, dass das Ziel Parameter ignoriert, und deckt keinen Verkehr ab, der YARP umgeht.

Wählen Sie eines von zwei Designs. Braucht kein legitimer Client Tunnel, deaktivieren Sie die Middleware und lehnen alle Signale am Edge ab. Sind sie erforderlich, dokumentieren Sie einen Eingang, sperren Alternativen, normalisieren vor Kontrollen und testen native und getunnelte Form als dieselbe Aktion.

Inventarisieren Sie zuerst. Suchen Sie Middleware, Request-Wrapper, _method, die drei Namen und Zuweisungen der Methode. Prüfen Sie Routengruppen und alte Kompatibilitätsmodule, die Upgrades überlebt haben.

Untersuchen Sie danach den Netzwerkpfad. CDN, Load Balancer, Service Mesh, Proxy, Server und Framework können Header verschieden normalisieren und protokollieren. Stellen Sie sicher, dass keine öffentliche Route die Ablehnung umgeht. Ein internes Netz macht aufrufergesteuerte Header nicht vertrauenswürdig.

Entfernung kann legitime Clients brechen und wird deshalb verschoben. Messen Sie zunächst die Präsenz, ohne Secrets oder ganze Bodys zu protokollieren. Kündigen Sie die Abschaltung an, lassen Sie Tests klar scheitern und entfernen Sie Serverunterstützung und Edge-Regel gemeinsam. Versteckte Kompatibilität dauerhaft zu behalten kostet mehr als die Migration.

Protokolle brauchen Request-Zeile und gewählte Aktion

Ein Audit sollte Transportmethode, effektive Methode, Quelle, normalisierten Wert, Route, Identität, Ziel, Entscheidung, Antwort und Ergebnis speichern. Ohne beide Methoden lässt sich der Weg von POST zu DELETE nicht erklären. Ohne Ergebnis zeigt der Datensatz nur Absicht.

Protokollieren Sie auch mehrdeutige Ablehnungen. Ein Konflikt ist sicherheitsrelevant, auch ohne Handler. Speichern Sie Namen und normalisierte Token, nicht Authorization-Werte oder fremde Bodys. Begrenzen und maskieren Sie ungültige Werte, damit Steuerzeichen keine Logzeilen fälschen.

Verbinden Sie Schichten mit einer ID vom ersten vertrauenswürdigen Hop. Ersetzen oder separieren Sie jede externe ID. Edge, Resolver, Freigabe, Anwendung und asynchroner Worker müssen dieselbe vertrauenswürdige ID tragen.

Benennen Sie Felder präzise. method lädt Komponenten zu verschiedenen Bedeutungen ein. Nutzen Sie transport_method für die Zeile und effective_method für die Aktion. Ordnen Sie originalMethod bewusst zu, statt überall dieselbe Bedeutung anzunehmen.

Sallyport führt den HTTP-Aufruf eines Agenten aus, ohne ihm das Credential offenzulegen, und protokolliert den Aufruf im Activity-Journal. Diese Trennung macht einen Override nicht sicher; die Prüfung muss vor der Ausführung weiterhin die effektive Methode bestimmen.

Manipulationsnachweis zählt nach einem autonomen Lauf. Eine Hash-Kette macht Bearbeitung sichtbar, stellt fehlende Semantik aber nicht wieder her. Protokollieren Sie die normalisierte Aktion zum Entscheidungszeitpunkt, nicht in einem späteren Job, der sie errät.

Das Prüf-Dashboard sollte Abweichungen zeigen. transport_method != effective_method nach Dienst und Quelle zu zählen deckt unerwarteten Kompatibilitätsverkehr auf. Alarmieren Sie bei neuen Quellen, Mehrdeutigkeit und destruktiven effektiven Methoden, deren Freigabe nur die äußere Methode enthielt.

Ein Regressionstest muss sicher fehlschlagen

Die dauerhafte Korrektur ist ein Vertragstest über den eingesetzten Pfad, der fehlschlägt, sobald ein nicht freigegebener Override Zustand ändert. Ein Unit-Test des Resolvers erkennt keine verschwundene Proxy-Regel, verschobene Middleware oder neuen Eingang.

Definieren Sie das Ergebnis jedes Falls. Bei deaktiviertem Tunnel muss jedes Signal einen dokumentierten 4xx ohne Änderung liefern. Bei einer erlaubten Konvention muss ihr DELETE dem nativen bei Autorisierung, Freigabe, Routing und Audit entsprechen. Konflikte und unbekannte Token müssen vor Effekten scheitern.

Nehmen Sie diese Assertions auf:

• die Freigabe nennt die effektive Methode;
• native und getunnelte Form erhalten dieselbe Autorisierung;
• abgelehnte Eingaben ändern weder Version noch Effektzähler;
• beide Methoden stehen unter einer vertrauenswürdigen ID;
• direkter Upstream-Zugriff umgeht die Normalisierung nicht.

Führen Sie die Suite bei Änderungen an Proxy, Framework, Authentifizierung, Freigabe, Routen oder Agentenwerkzeug aus. Ein nächtlicher Lauf erkennt Drift, ein Release-Gate bewusste Änderungen. Isolieren Sie das Fixture von Nutzerdaten.

Behandeln Sie eine neu akzeptierte Konvention als Sicherheitsänderung, auch wenn das Framework sie Kompatibilität nennt. Verlangen Sie Eigentümer, Bedarf, Priorität, äußere Methode, effektive Methodenmenge und Entfernungskriterium. Sonst erweitert eine Middleware-Zeile unbemerkt das Aktionsvokabular der Kontrollen.

Ein sauberes System trägt eine Aktionsbeschreibung vom Eingang bis zum Ergebnis. Steht im Transport POST und in der Anwendung DELETE, muss der Unterschied sichtbar sein, bevor Mensch oder Komponente zustimmen. Später bleibt nur die Rekonstruktion.