HTTP QUERY: Die neue Methode zwischen GET und POST

In fast jeder größeren Schnittstelle findet sich ein Endpunkt namens POST /search. Er funktioniert, und er verschweigt etwas Wesentliches. POST sagt HTTP nicht, dass diese Operation nur liest, denn die Methode ist weder als sicher noch als idempotent definiert. Clients, Proxys und Caches können deshalb nicht dieselben Annahmen treffen wie bei GET. Sie behandeln die Anfrage wie eine Bestellung, die man besser nicht zweimal abschickt.

Seit Juni 2026 gibt es dafür einen Standard. RFC 10008 definiert die HTTP-Methode QUERY, die sich verhält wie GET und dabei einen Request-Body trägt wie POST (1). Erweiterungen des HTTP-Methodenrepertoires sind selten, das zuletzt verbreitete neue Verb war PATCH im Jahr 2010. Einer der drei Autoren ist Julian Reschke von greenbytes aus Münster, der schon die WebDAV-Methode SEARCH mitverfasst hat, aus der die Idee ursprünglich hervorging.

Eine einfache Suche passt bequem in die Adresszeile: GET /feed?q=foo&limit=10. Sobald aber verschachtelte Filter, Listen von Kategorien oder ganze Abfrageausdrücke dazukommen, wird die URL zum Nadelöhr. Eine feste Längengrenze gibt es nicht, weil eine Anfrage viele voneinander unabhängige Systeme passiert, von denen jedes sein eigenes Limit setzen kann. Die HTTP-Spezifikation empfiehlt lediglich, mindestens 8000 Oktette zu unterstützen. Dazu kommt der Aufwand, strukturierte Daten überhaupt erst in eine gültige URL zu kodieren.

Schwerer wiegt oft ein anderer Punkt. URLs landen weit häufiger in Server-Logs, Browserverläufen und Lesezeichen als der Inhalt einer Anfrage. Wer in einem Mitgliederverzeichnis nach Namen oder in einer Fachdatenbank nach sensiblen Begriffen sucht, hinterlässt diese Spuren mit jedem GET. QUERY ist damit allerdings kein Datenschutzmechanismus: Auch Request-Bodies können von Anwendungen, Proxys oder Monitoring-Systemen protokolliert werden. Außerdem zwingt GET jede Filterkombination vollständig in die URL, selbst wenn die Abfrage längst zu komplex ist, um dort noch lesbar oder handhabbar zu sein.

Der übliche Ausweg über POST löst das Längenproblem und schafft ein neues. Aus einem POST-Request allein ist nicht erkennbar, dass er nur liest. Ein Client darf ihn nach einem Verbindungsabbruch nicht ohne Weiteres automatisch wiederholen, und eine zwischengespeicherte POST-Antwort darf keine spätere identische POST-Anfrage beantworten.

Äußerlich unterscheidet sich QUERY kaum von POST. Die Abfrage steht im Body, der Medientyp im Content-Type. Ein Beispiel für die Programmsuche eines Fachkongresses:

Der Content-Type ist dabei Pflicht. Fehlt er oder passt er nicht zum Inhalt, muss der Server die Anfrage ablehnen. Ein nachträgliches Erraten des Formats, das sogenannte Content Sniffing, schließt die Spezifikation ausdrücklich aus.

Im Browser lässt sich QUERY direkt mit fetch() senden:

Solange die Anfrage an denselben Origin geht, also an dieselbe Kombination aus Schema, Host und Port, bleibt es dabei. Bei Cross-Origin-Anfragen schickt der Browser vorher einen CORS-Preflight, weil QUERY nicht zu den CORS-sicheren Methoden gehört. Der Server muss QUERY dann in Access-Control-Allow-Methods freigeben. Für einen schnellen Test auf der Kommandozeile reicht curl:

Bis hierhin wirkt QUERY wie ein GET mit Body. Die eigentlich überraschende Idee der RFC steckt in der sogenannten äquivalenten Ressource. Der Server darf einer Abfrage nachträglich eine eigene URL geben und diese im Location-Header zurückliefern. Unter dieser Adresse lässt sich dieselbe Suche später per GET wiederholen, ohne den Body erneut zu schicken. Content-Location wiederum verweist auf genau das gelieferte Ergebnis, das auch nur vorübergehend verfügbar sein kann.

Damit kehrt ein altes Prinzip des Webs zurück, nach dem jede wichtige Ressource eine eigene Adresse haben soll. Die Abfrage behält ihre URL, deren Form allerdings jetzt der Server bestimmt. Eine zusammengestellte Programmauswahl wird teilbar, und mit If-None-Match fragt der Client beim nächsten Mal nur noch, ob sich etwas geändert hat. Ist das nicht der Fall, antwortet der Server mit 304 Not Modified. Wer sensible Suchbegriffe verarbeitet, sollte die erzeugten URLs so wählen, dass sie keine Teile der ursprünglichen Abfrage enthalten, sonst landet im Log genau das, was QUERY vermeiden sollte. Die RFC formuliert das als klare Empfehlung.

Der Server kann auch indirekt antworten. Mit 303 See Other liefert er kein Ergebnis, sondern nur die Adresse der gespeicherten Abfrage, die der Client anschließend per GET abruft.

Antworten auf QUERY sind ausdrücklich cachebar. Dafür muss der Cache-Key allerdings den Request-Body und die zugehörigen Metadaten einbeziehen, also auch den Medientyp. Caches dürfen den Inhalt vorher normalisieren, etwa Kompression entfernen oder JSON einheitlich formatieren, allerdings nur für die Berechnung des Schlüssels. Fällt diese Normalisierung anders aus als die Verarbeitung auf dem Server, liefert der Cache im schlimmsten Fall die Antwort auf eine ganz andere Frage.

Hive Security leitet daraus unter anderem Risiken für Cache Poisoning und Cache Deception ab (2). Die RFC selbst räumt ein, dass Caching bei QUERY aufwendiger ist als bei GET, weil der Cache erst den gesamten Body lesen muss, bevor er den Schlüssel kennt. Hier schließt sich der Kreis zur äquivalenten Ressource: Liefert der Server eine Location mit, können Clients für Folgeanfragen auf GET umsteigen, und der Cache arbeitet wieder mit einer gewöhnlichen URL.

RFC 10008 empfiehlt für Fehlerfälle konkrete Statuscodes, die sich gut unterscheiden lassen. 400 steht für einen fehlenden oder zum Inhalt unpassenden Medientyp, 415 für ein Format, das der Endpunkt nicht versteht. Ist die Abfrage formal korrekt, aber inhaltlich nicht ausführbar, passt 422. Die Spezifikation nennt als Beispiel eine syntaktisch einwandfreie SQL-Abfrage auf eine Tabelle, die nicht existiert. Verlangt der Client über Accept ein Antwortformat, das der Server nicht liefert, folgt 406.

Eine schlanke Umsetzung in PHP kann so aussehen:

Der Medientyp wird dabei vor einem möglichen Semikolon abgetrennt und exakt verglichen, sodass auch application/json; charset=utf-8 sauber durchläuft. Der neue Header Accept-Query verrät dem Client, welche Abfrageformate ein Endpunkt annimmt. Er ist als Structured Field definiert und gilt für alle URLs mit demselben Pfad, unabhängig von angehängten Parametern.

Ob ein Server QUERY beherrscht, lässt sich per OPTIONS prüfen, eine entsprechende Antwort kann QUERY im Allow-Header aufführen. Alternativ probiert der Client die Methode direkt aus. Antwortet der Server mit 405 Method Not Allowed, muss er den Allow-Header mitsenden, und der Client weiß, welche Methoden stattdessen zur Verfügung stehen.

Zwischen Client und Anwendung liegen meist mehrere Schichten. Regelwerke in Web Application Firewalls, Proxys, Load Balancern und CSRF-Middleware sind in der Regel für GET, POST, PUT, DELETE und PATCH geschrieben. Manche Systeme lehnen QUERY deshalb ab, andere leiten die Methode anders weiter oder prüfen sie weniger streng als POST. Vor dem ersten produktiven Einsatz lohnt ein Blick auf die gesamte Kette.

Mindestens ebenso wichtig ist die Disziplin auf der eigenen Seite. Ein QUERY-Endpunkt darf semantisch keine Zustandsänderung anfordern. Protokolle, Statistiken oder ein vorgewärmter Cache sind davon nicht betroffen, fachliche Daten dagegen schon. Wer über QUERY dennoch Datensätze verändert, unterläuft die Sicherheits- und Wiederholungsannahmen aller beteiligten Systeme.

Die Unterstützung wächst, bleibt aber ungleich verteilt. OpenAPI 3.2 kennt QUERY bereits als eigene Operation (3). Der HTTP-Parser von Node.js unterstützt die Methode ebenfalls, bei höheren Client-Abstraktionen und Frameworks verlief die Einführung später. Spring Framework bietet erste native Unterstützung in der Vorschau auf Version 7.1, deren finale Fassung für November angekündigt ist, während die stabile 7.0-Linie QUERY noch nicht regulär abbildet (4). HTML-Formulare kennen weiterhin nur GET und POST.

Für den Einstieg bieten sich deshalb Schnittstellen an, bei denen die gesamte Strecke vom Client bis zum Server unter eigener Kontrolle liegt, etwa interne APIs oder die Kommunikation zwischen zwei Diensten. Ein bestehender POST-Endpunkt kann während der Übergangszeit parallel weiterlaufen, während Allow und Accept-Query den Clients signalisieren, dass es einen direkteren Weg gibt. Wo QUERY nicht ankommt, bleibt der alte Weg offen.

Eine Suche darf jetzt sagen, dass sie nur sucht.