Zusammenfassung

  • QUERY trägt den Abfrageausdruck im Request-Inhalt und ist als sicher und idempotent registriert. Diese Eigenschaft verpflichtet die Implementierung; sie bescheinigt einem beliebigen Handler keine Freiheit von Geschäftswirkungen.
  • Inhalt und relevante Metadaten gehören in den Cache-Key. Retry, Redirect, Validatoren, Accept-Query und eine äquivalente URI verteilen Befugnisse auf Client, Cache und Origin.

Eine Analyseanwendung soll verschachtelte Filter und eine Projektion übermitteln. GET wäre für einen Abruf passend, doch RFC 9110 weist empfangenem GET-Inhalt keine allgemeine Semantik zu. POST transportiert den Body, lässt nach einem Verbindungsabbruch aber offen, ob erneutes Senden eine Geschäftshandlung verdoppelt.

Der im Juni 2026 als Proposed Standard veröffentlichte RFC 10008 schafft dafür QUERY. Inhalt ist Pflicht, der Medientyp bezeichnet die Abfragesprache, und Inhalt plus relevante Metadaten definieren die Frage an die Zielressource. IANA führt QUERY als sicher und idempotent und Accept-Query als permanentes Feld.

QUERY ist weder GET mit Body noch umbenanntes POST. Sicher heißt: Die angeforderte Bedeutung ist Lesen, nicht Änderung eines Geschäftsbestands. Idempotent heißt: Mehrere identische Requests haben dieselbe beabsichtigte Wirkung wie einer; identische Antwortbytes sind nicht versprochen. Reservierung, Abbuchung, Freigabe oder Verbrauch eines Rechts bleiben unsicher, auch wenn Deduplizierung die zweite Ausführung abfängt.

Methodeneigenschaften erlauben anderen, sich darauf zu verlassen

Clients automatisieren sichere Methoden. Transportbibliotheken dürfen eine idempotente Methode nach einem Fehler mit unklarem Ausführungszeitpunkt eher wiederholen. Caches wenden Regeln auf Methoden an, die sie verstehen. Ein Origin, der QUERY anbietet, stellt diesen Akteuren eine belastbare Zusage zur Verfügung.

Ein Router-Attribut ist noch kein Beleg. Die Spur muss Methode, Fingerprint von Inhalt und Medientyp, Identitätskontext, Anwendungsausführung, Effekte und ausgelieferte Repräsentation verbinden. Beim Retry muss sie zeigen, ob der erste Versuch die Geschäftslogik erreichte und ob der zweite eine verbotene Änderung auslöste.

Begleitende Telemetrie kann mit einem sicheren Abruf vereinbar sein. Quotenabbau, Fortschreiben eines Geschäftscursors, Token-Verbrauch oder externer Auftrag sind dagegen Wirkungen des Requests. Bewertet wird die Folge für Nutzer und Dritte, nicht der Funktionsname.

Der Body gehört zur Cache-Identität

RFC 10008 verlangt, Request-Inhalt und relevante Content-Metadaten in den Cache-Key aufzunehmen. Dieselbe URI mit zwei Abfragekörpern stellt zwei Fragen. Ein Key nur aus Methode und URI kann die Antwort eines Filters für einen anderen liefern.

Der Cache muss möglicherweise den gesamten Inhalt lesen, bevor er den Key bilden kann. Größenlimit, Speicher, Latenz und Backpressure werden Teil des Betriebsvertrags. Was die URI verlässt, verschwindet nicht, sondern wird Identitätsmaterial einer weiteren Schicht.

Kennt ein Cache den Medientyp, darf er semantisch bedeutungslose Unterschiede normalisieren. Damit übernimmt er semantische Autorität. Definierte Leerzeichen zu vereinheitlichen ist nicht dasselbe wie eine positionsabhängige Liste zu sortieren. Eine falsch-positive Normalisierung beantwortet die falsche Frage. no-transform ist eine HTTP-Anweisung, kein Auditbeleg dafür, dass niemals eine kanonische Schlüsselform entstand.

Tests müssen beide Richtungen abdecken: verschiedene Schreibweisen derselben Bedeutung und ähnlich wirkende, aber unterschiedliche Bedeutungen. Unicode, Zahlen, Duplikate, Defaults, Content-Encoding, Signaturen und Authentisierungspartitionen gehören dazu. Ohne eine von allen Parsern geteilte Regel ist Trennung der reversible Ausgangspunkt.

Ein Name verlängert die Lebensdauer des Ergebnisses

Die äquivalente Ressource wird aus Zielressource, QUERY-Inhalt und Metadaten abgeleitet. Der Origin kann ihr eine URI geben, damit später GET genügt. Aus einem flüchtigen Ausdruck wird ein kopierbarer, speicherbarer Name.

Location und Content-Location sind keine Synonyme. Bei erfolgreichem QUERY kann Location eine äquivalente oder Query-Ressource für GET bezeichnen. Content-Location ordnet der gelieferten Repräsentation eine URI nach HTTP-Semantik zu. Wer beides als kanonische URL behandelt, verliert die Aussage darüber, was der Origin benannt hat.

Benennung kann vertrauliche Inhalte erneut offenlegen. Enthält die erzeugte URI Konto oder Filter, gelangen diese wieder in History, Logs und Referenzen. Ein opaker Bezeichner reduziert Sichtbarkeit, schafft aber Fragen zu Laufzeit, Zugriff und Widerruf. Die URI kann den ursprünglichen Berechtigungskontext überleben.

RFC 3986 regelt Syntax, nicht Vertraulichkeit oder Haltbarkeit. Der benennende Origin trägt die Folgen seiner dauerhaften Oberfläche.

Redirects regieren die Methode

Bei 301, 302, 307 und 308 bleibt QUERY erhalten; historische POST-Ausnahmen gelten nicht. Erst 303 ordnet GET an. Die erste Gruppe sendet Methode und Inhalt weiter, die zweite verweist auf eine Ressource.

Konvertiert ein Gateway QUERY gewohnheitsmäßig zu GET, kann es Inhalt verlieren oder in die URI zurückschreiben. Eine Konvertierung zu POST beseitigt die Grundlage des Retry. Jeder Status, Origin-Wechsel, Credential-Pfad und jedes Größenlimit ist getrennt zu prüfen.

Bei conditional QUERY beziehen sich Validatoren auf die Repräsentation, die GET für die äquivalente Ressource ausgewählt hätte. Content Negotiation und Autorisierung bleiben wirksam. Ein Hash des Abfragekörpers ist nicht automatisch ein Validator des Ergebnisses.

Accept-Query ist frischer, begrenzter Nachweis

Accept-Query kündigt akzeptierte Medientypen als List nach RFC 9651 an. Das Signal gilt für denselben Pfad ohne Beachtung der URI-Query-Komponente; relevant ist der jüngste noch frische Wert.

Es beweist weder die Gültigkeit jedes Ausdrucks noch die Einigkeit aller Knoten. Antwort, Frische, Pfad und Deployment-Version müssen erhalten bleiben.

Im Browser gilt eine weitere Grenze. QUERY gehört im Fetch Standard nicht zu den CORS-safelisted methods. Cross-Origin-Nutzung braucht Preflight. Korrekte Anwendungsunterstützung reicht nicht, wenn Gateway, WAF oder CORS-Policy die Methode ablehnen.

Außerhalb der URI heißt nicht geheim

QUERY kann komplexe Filter aus URI-Logs und kopierten Links fernhalten. Der Inhalt durchläuft trotzdem Client, Browserwerkzeuge, TLS-Terminierung, Gateways, Caches, Tracing und Origin. Er kann protokolliert, gesampelt, erneut gesendet oder durch eine erzeugte URI wieder offengelegt werden.

Lu Hengs Trennung von formaler Kontrolle und praktischer Datenhoheit trifft den Punkt: Der Origin definiert die Semantik; tatsächliche Verwahrung verteilt sich auf alle Empfänger von Inhalt oder Fingerprint.

Sein Modell von minimaler gemeinsamer Spezifikation und lokaler Entscheidung erklärt die Grenze. Gemeinsam sind Methode, Eigenschaften, Cache-Pflicht, Redirect und Capability-Feld. Sprache und Name bleiben beim Origin, Senden und Retry beim Client, korrekte Wiederverwendung beim Cache.

Die Vorrangstellung laufenden Codes legt den Beweisort fest. Der RFC belegt die Erwartung. Nur Ausführungsspuren belegen Sicherheit, Idempotenz, vollständige Keys und diskrete Namen.