Aktuelles

HTTP bekommt eine neue Methode: QUERY (RFC 10008)

Manchmal passieren die spannendsten Sachen in der Web-Entwicklung ziemlich leise. Kein großes Launch-Event, kein Keynote-Moment, keine Trending-Hashtags über Nacht - einfach ein neues RFC-Dokument, das irgendwann im Juni auf den Servern der IETF landet. Und trotzdem: Wenn HTTP nach 16 Jahren eine neue Standard-Methode bekommt, dann sollte man kurz aufhorchen. Die letzte war PATCH, im Jahr 2010. Seitdem: nichts. Und jetzt, im Juni 2026, kommt QUERY dazu, offiziell verabschiedet als RFC 10008.

Wer jetzt nur "Bahnhof" versteht, kein Problem, einfach weiterblättern. Für alle, die Internet-Protokollen ein gewisses Interesse entgegenbringen, habe ich mir das Ganze mal in Ruhe angeschaut, weil so eine Standardisierung wirklich nicht alle Tage passiert - und weil sie tatsächlich ein Problem löst, das uns in der Praxis öfter mal begegnet.

Das Problem, von dem viele gar nicht wissen, dass es eins ist

Jeder, der APIs baut, kennt diese Situation: Man braucht einen Such-Endpoint. Nutzer sollen filtern können, sortieren, mehrere Kriterien kombinieren, vielleicht noch Paginierung dazu. Klingt erstmal nach einem klassischen GET-Request - schließlich verändert man ja nichts, man liest nur Daten. Genau dafür ist GET gemacht: sicher (safe) und wiederholbar (idempotent), das heißt, ein Client oder ein Proxy kann den Request jederzeit noch mal abschicken, ohne dass irgendwas kaputtgeht.

Das Problem fängt an, sobald die Suchkriterien komplexer werden. Ein paar Filter, verschachtelte UND/ODER-Bedingungen, Volltextsuche, mehrere Sortierfelder - und plötzlich wird aus der schönen, sauberen URL ein Monster-String mit hunderten Zeichen. Und dann wird's technisch unangenehm: Es gibt keine verbindliche Obergrenze für die Länge einer URL, aber viele Systeme entlang der Strecke - Proxies, Load Balancer, alte Server-Konfigurationen - ziehen irgendwo ihre eigene, oft undokumentierte Grenze. Man weiß nie so genau, wo es kracht.

Also, was macht man in der Praxis? Man greift zu POST. Fast jede API, die ich in den letzten Jahren gesehen habe, hat irgendwo einen Endpoint wie POST /search oder POST /reports. Funktioniert technisch einwandfrei - man kann beliebig komplexe Daten im Body mitschicken. Nur: Es ist im Grunde eine kleine Notlüge gegenüber dem Protokoll. POST bedeutet in der HTTP-Semantik "hier verändert sich etwas", nicht "lies mal diese Daten für mich". Und diese Notlüge hat Konsequenzen. Caches behandeln POST-Antworten grundsätzlich anders, weil sie nicht wissen können, ob der Request wirklich harmlos war. Automatische Retry-Mechanismen zögern bei POST, weil im Fehlerfall unklar ist, ob der ursprüngliche Request vielleicht doch schon etwas angelegt hat. Und Browser fragen bei manchen POST-Aktionen sicherheitshalber nach, ob man die Anfrage wirklich noch mal abschicken will.

Genau diese Lücke zwischen GET und POST füllt jetzt QUERY.

Was QUERY konkret macht

Die Idee ist eigentlich angenehm simpel: QUERY verhält sich wie POST, was den Request-Body angeht - man kann strukturierte Daten mitschicken, egal wie komplex. Aber semantisch verhält sich QUERY wie GET: sicher und idempotent. Der Server verspricht quasi: "Ich verändere hier nichts, du kannst mich beliebig oft wiederholen lassen."

Ein Beispiel aus dem RFC, leicht angepasst:

QUERY /contacts HTTP/1.1
Host: example.org
Content-Type: application/x-www-form-urlencoded
Accept: application/json

select=surname,givenname,email&limit=10&match="email=*@example.*"

Die Suchkriterien wandern also, genau wie bei POST, in den Body statt in die URL. Der entscheidende Unterschied: Der Server muss laut Spezifikation sicherstellen, dass dabei kein Zustand verändert wird. Das ist keine Konvention mehr, sondern Teil der Methodendefinition.

Interessant wird's bei den Details, die das RFC mitliefert:

1. Content-Type ist Pflicht. Ein QUERY-Request ohne (oder mit inkonsistentem) Content-Type-Header muss der Server ablehnen. Macht Sinn - ohne zu wissen, in welchem Format die Anfrage kommt (SQL? JSONPath? klassisches Formular-Encoding?), kann der Server sie schlicht nicht interpretieren.
2. Server können Ergebnis-URIs vergeben. Das fand ich persönlich den cleversten Teil der ganzen Spec. Ein Server kann in der Antwort per Location-Header eine URI mitschicken, unter der man dieselbe Anfrage künftig per simplem GET wiederholen kann - ganz ohne den Body noch mal zu schicken. Oder per Content-Location eine URI für genau dieses Ergebnis, quasi ein Snapshot. Damit lassen sich sogar "gespeicherte Suchen" bauen, die man verlinken oder cachen kann, obwohl die ursprüngliche Anfrage viel zu komplex für eine URL war.
3. Es gibt einen neuen Header: Accept-Query. Damit kann eine Ressource ankündigen, dass sie QUERY überhaupt unterstützt - und welche Formate sie akzeptiert. Zum Beispiel:

Accept-Query: "application/x-www-form-urlencoded", "application/sql"

Praktisch für die Discovery: Ein Client kann per OPTIONS oder HEAD vorher nachfragen, bevor er einen vollständigen QUERY-Request abschickt.

Caching funktioniert - ist aber komplizierter als bei GET. Bei GET reicht die URL als Cache-Key. Bei QUERY muss der komplette Body mit in den Cache-Key einfließen, inklusive relevanter Metadaten wie dem Content-Type. Das RFC erlaubt Caches sogar, den Body vor dem Hashing zu normalisieren (z. B. Encoding-Unterschiede rauszurechnen), um die Trefferquote zu verbessern. Klingt nach einer netten Idee, ist in der Praxis aber deutlich aufwendiger zu implementieren als ein simpler URL-Cache.

Der Elefant im Raum: Browser-Support und CORS

Und jetzt kommt der Teil, der für uns als Agentur, die viel im Browser-Kontext arbeitet, am relevantesten ist: QUERY zählt (noch) nicht zu den sogenannten CORS-safelisted Methods. Das heißt konkret: Sobald JavaScript im Browser eine QUERY-Anfrage an eine andere Origin schickt, löst das einen Preflight-Request aus - der Browser schickt vorher automatisch ein OPTIONS, um zu prüfen, ob der Server QUERY überhaupt erlaubt. Das steht sogar explizit so im RFC drin, unter "Security Considerations".

Für same-origin-Anfragen (also innerhalb derselben Domain, was bei vielen unserer Projekte ohnehin der Standardfall ist) spielt das keine Rolle. Aber sobald man plant, QUERY für eine öffentliche API einzusetzen, die von fremden Domains aus angesprochen wird, muss der Server sauber auf die Preflight-Anfrage antworten - konkret mit einem Access-Control-Allow-Methods-Header, der QUERY mit auflistet.

Technisch spricht aber nichts dagegen, es schon jetzt auszuprobieren. fetch() und auch Bibliotheken wie Axios erlauben beliebige Methodennamen, QUERY funktioniert also bereits im Code:

const response = await fetch('/api/produkte', {
  method: 'QUERY',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    kategorie: 'schuhe',
    preisMax: 100,
    sortierung: 'preis-aufsteigend'
  })
});

const daten = await response.json();

Für den Ernstfall würde ich aber unbedingt einen Fallback einbauen, falls der Server (oder irgendein Proxy dazwischen) mit QUERY noch nichts anfangen kann - zum Beispiel, indem man bei einem 405 (Method Not Allowed) automatisch auf POST zurückfällt.

Und auf der PHP-Seite?

Da PHP bei uns im Alltag die Hauptrolle spielt: Grundsätzlich ist QUERY erstmal einfach ein String im Request - PHP kümmert sich schon lange nicht mehr nur um GET und POST, sondern verarbeitet jede Methode, die im Request-Kopf steht. $_SERVER['REQUEST_METHOD'] liefert bei einem entsprechenden Request eben "QUERY" zurück, und der Body lässt sich ganz normal über php://input auslesen:

if ($_SERVER['REQUEST_METHOD'] === 'QUERY') {
    $body = file_get_contents('php://input');
    $contentType = $_SERVER['CONTENT_TYPE'] ?? '';

    if (str_contains($contentType, 'application/json')) {
        $filter = json_decode($body, true);
        // ... Suchlogik mit $filter ausführen
    }

    header('Content-Type: application/json');
    echo json_encode($ergebnis);
    exit;
}

Klingt fast schon unspektakulär - und genau das ist ja auch der Punkt. Das eigentliche Problem liegt nicht bei PHP selbst, sondern bei allem, was vor PHP sitzt: Webserver-Konfiguration, eventuelle Method-Whitelists in .htaccess oder Nginx-Configs, WAFs, CDN-Regeln. Wer zum Beispiel mit limit_except in Apache arbeitet oder Methoden explizit whitelistet, muss QUERY dort aktiv ergänzen, sonst landet die Anfrage nie im PHP-Skript.

Wie sieht's mit der Unterstützung sonst aus?

Ehrlich gesagt: durchwachsen, aber das ist bei einem Standard, der gerade erst ein paar Wochen alt ist, auch kein Wunder. Node.js verarbeitet QUERY laut aktuellen Berichten bereits seit einer Weile nativ. Spring (Java) hat einen Pull Request in der Pipeline, aber die offizielle Unterstützung fehlt noch. Rails diskutiert das Thema aktuell. Browser selbst evaluieren die Implementierung noch - für native HTML-Formulare mit method="query" gibt es sogar schon einen offenen Vorschlag bei WHATWG. Bemerkenswert finde ich, dass unter den drei Autoren des RFCs Leute von Cloudflare und Akamai sitzen - das lässt vermuten, dass CDN- und Cache-Infrastruktur eher früher als später mitzieht, weil genau da der größte Nutzen liegt.

Kurz gesagt: Wer heute schon experimentieren will, kann das server- und clientseitig problemlos tun, solange man beide Enden selbst kontrolliert. Für öffentliche APIs, die auf fremde Clients, Proxies oder ältere Infrastruktur treffen, würde ich aktuell noch nicht voll darauf setzen - sondern eher beobachten und mit robusten Fallbacks arbeiten.

GET, POST oder QUERY - eine kleine Übersicht

	GET	QUERY	POST
Sicher (safe)	ja	ja	nein, potenziell zustandsändernd
Idempotent	ja	ja	nein, potenziell nicht
Request-Body	keine definierte Semantik	ja, erwartet	ja, erwartet
Cachebar	ja	ja	eingeschränkt
CORS-safelisted	ja	nein, Preflight nötig	teilweise

Zu guter Letzt

QUERY ersetzt weder GET noch POST - es schließt eine Lücke, die es vorher schlicht nicht gab. Für kleine, einfache Suchanfragen bleibt GET nach wie vor die richtige Wahl, allein schon, weil man das Ergebnis als URL teilen oder als Bookmark speichern kann. Für alles, was komplexer wird - mehrstufige Filter, Reporting-Abfragen, Volltextsuchen mit vielen Parametern, vielleicht auch strukturierte Anfragen an eine Vektordatenbank oder ein RAG-System - bekommt man mit QUERY endlich ein Werkzeug, das ehrlich benennt, was eigentlich passiert: Es wird gelesen, nicht verändert.

Klar ist auch: Bis das im Alltag wirklich ankommt, wird sicher noch ein bisschen Zeit vergehen. Browser, Frameworks, Proxies, WAFs - überall muss die neue Methode erstmal explizit erlaubt und verstanden werden, und solche Dinge brauchen ihre Zeit. Aber die Richtung ist gesetzt, und für uns als Agentur, die viel mit eigenen APIs und Suchfunktionen arbeitet, lohnt es sich definitiv, das Thema auf dem Schirm zu behalten. Vielleicht nicht heute schon produktiv einsetzen - aber im nächsten Projekt mit komplexer Such- oder Filterlogik ruhig mal in Betracht ziehen, ob POST /search diesmal nicht einfach QUERY /search heißen sollte.

---

Foto: BillyCM

Quelle: RFC 10008 - The HTTP QUERY Method, IETF, Juni 2026, verabschiedet als Proposed Standard im Rahmen der HTTPBIS Working Group.

10.07.2026