HTTP QUERY hat einen RFC, aber kaum Implementierungen

HTTP hat eine neue Methode für Suchanfragen. Die IETF veröffentlichte RFC 10008, „The HTTP QUERY Method“ im Juni 2026 als Proposed Standard der httpbis-Arbeitsgruppe. Drei Monate später berichtete InfoQ im September 2026, dass kein Projekt einen abgeschlossenen Produktionseinsatz angekündigt hat.

Die Methode wurde von Julian Reschke, James M. Snell und Mike Bishop geschrieben. Sie existiert, um ein Problem zu lösen, um das jeder API-Entwickler schon mindestens einmal herumgearbeitet hat.

Die Lücke zwischen GET und POST

Eine Suchanfrage will zwei Dinge gleichzeitig, und bis jetzt zwang HTTP dazu, sich für eines zu entscheiden.

GET ist sicher, das heißt, es ändert nichts auf dem Server. Es ist idempotent, ein Client kann es also folgenlos wiederholen, und es ist cachebar. Der Haken ist, dass alles, was man anfragt, in die URL passen muss. Lange Filter stoßen an Längengrenzen, sie landen in den Zugriffsprotokollen des Servers, und verschachtelte Strukturen lassen sich nur umständlich kodieren.

POST transportiert einen Body beliebiger Größe und Form. Es ist aber weder als sicher noch als idempotent definiert, also überspringen Caches es, Clients können es nicht gefahrlos wiederholen, und alles dazwischen muss annehmen, dass es etwas verändert hat.

QUERY nimmt von beiden die nützliche Hälfte. Der RFC definiert es so, dass „das Anfrageziel den mitgelieferten Inhalt auf sichere und idempotente Weise verarbeitet“ und dann mit dem Ergebnis antwortet. Es ist sicher, idempotent und cachebar, und es transportiert einen Request-Body. Der RFC beschreibt den Fall, für den es gedacht ist, als einen, bei dem „die übermittelten Daten zu umfangreich sind, um in der URI der Anfrage kodiert zu werden“.

Ein paar Regeln gehören dazu. Content-Type ist Pflicht: „Server MÜSSEN die Anfrage fehlschlagen lassen, wenn das Anforderungsfeld Content-Type ... fehlt oder nicht mit dem Inhalt der Anfrage übereinstimmt.“ Über einen Accept-Query-Header kann ein Server bekannt geben, welche Abfrageformate er akzeptiert. Bedingte Anfragen funktionieren mit den üblichen HTTP-Validierungs-Headern.

Caching ist der Teil, der stimmen muss

Eine Methode mit Body cachebar zu machen ist das schwierige Problem, das der RFC lösen muss. Ein Cache schlüsselt normalerweise nach der URL, und die Bedeutung einer QUERY-Anfrage steckt in ihrem Body.

Die Antwort von RFC 10008 lautet, dass Cache-Schlüssel den vollständigen Inhalt der Anfrage zusammen mit den zugehörigen Metadaten einbeziehen müssen. Ein Cache, der den Body ignoriert, würde die Ergebnisse einer Suche für eine andere Suche ausliefern.

Der RFC erlaubt es einem Server außerdem, stattdessen eine URL für das Ergebnis zurückzugeben. Er kann den Ergebnissen eine URI zuweisen und mit Content-Location oder Location darauf verweisen, oder eine 303-Weiterleitung nutzen, wenn die Verarbeitung indirekt geschieht. Das gibt Clients ein einfaches GET, das sie ganz normal teilen, als Lesezeichen speichern und cachen können.

Sicherheit hat hier zwei Seiten. Eine Abfrage aus der URL in den Body zu verlagern ist ein Gewinn für den Datenschutz, denn der RFC merkt an, eine URI werde „mit größerer Wahrscheinlichkeit protokolliert“ als der Inhalt der Anfrage. Aber der oben beschriebene Ausweg kann das wieder zunichtemachen. Die Spezifikation sagt, eine Ergebnis-URI „SOLLTE so gewählt werden, dass sie keine sensiblen Teile“ der ursprünglichen Abfrage enthält. Browser fügen eine weitere Einschränkung hinzu: QUERY gehört nicht zu den freigegebenen (safelisted) Methoden, deshalb lösen Cross-Origin-Anfragen einen CORS-Preflight aus.

Wer es tatsächlich ausgeliefert hat

Hier trennt sich der Standard von der Praxis. InfoQ führt den Stand der Unterstützung als nachverfolgte Arbeit auf, nicht als fertige.

Projekt	Stand laut InfoQ
Rust-Crate http	Unterstützung gemergt
.NET	Issue wird verfolgt
Axum	Issue wird verfolgt
Quarkus	Issue wird verfolgt
Bruno	Issue wird verfolgt

Keines davon trägt ein angekündigtes Datum für den Produktionseinsatz. InfoQs Einschätzung lautet, dass „sich echte Verbreitung wahrscheinlich in Jahren messen lassen wird“, weil eine Methode erst nutzbar wird, wenn Clients, Server, Proxys und Caches entlang des Pfads sie alle verstehen. InfoQ stellt QUERY als optionale Ergänzung dar, nicht als Ersatz für GET oder POST.

Was das für Entwickler bedeutet

Schreiben Sie Ihre Such-Endpunkte nicht um. Eine QUERY-Anfrage, die auf eine Zwischenstation trifft, die die Methode nicht kennt, schlägt einfach fehl. Sie kontrollieren nicht jeden Hop zwischen Ihrem Client und Ihrem Server.

Der nützliche Schritt heute ist kleiner: Erkennen Sie, welche Ihrer Endpunkte ein verkapptes QUERY sind. Ein POST /search, das auf dem Server nichts verändert, ist genau das Muster, für das diese Methode existiert. Das zu wissen kostet jetzt nichts und macht die spätere Migration zu einer Umbenennung statt zu einem Neuentwurf.

Wenn Sie eine Client-Bibliothek, ein Server-Framework, einen Proxy oder einen Cache pflegen, sieht die Rechnung anders aus, denn Sie sind der Engpass, den der Zeitplan der Verbreitung beschreibt. Die Cache-Schlüssel-Anforderung des RFC ist der Teil, der am ehesten falsch implementiert wird, und ein Fehler dort bedeutet, die Suchergebnisse eines Nutzers an einen anderen auszuliefern.

Eine Warnung zur Sicherheitszusage. Dass QUERY sicher und idempotent ist, ist ein Versprechen, das Ihr Handler einhalten muss, nicht etwas, das die Methode erzwingt. Nichts hindert einen Server daran, innerhalb eines QUERY-Handlers Zustand zu verändern. Tut er es, wird jeder Wiederholungsversuch und jeder Cache entlang des Pfads zu einem Fehler, der schwer zu finden ist.