RFC 10008: Die neue HTTP-Methode, die headless Storefronts neu denken lässt

Die IETF hat im Juni 2026 einen neuen HTTP-Standard verabschiedet, über den im Commerce-Frontend bisher kaum jemand redet. RFC 10008 definiert eine neue HTTP-Methode: QUERY. Das klingt unspektakulär. Ich glaube, es ist keines.

Das Problem, das QUERY löst

Jedes headless Frontend lebt von Abfragen. Suche, Faceted Filtering, Produktlisten, GraphQL-Queries, Personalisierung - all das sind im Kern strukturierte Anfragen an einen Daten-Endpoint. Bisher hatten wir dafür exakt zwei Optionen, und beide sind unbefriedigend.

GET ist das Richtige semantisch: cachebar, safe (löst keinen State-Change aus), idempotent (gefahrlos wiederholbar). Aber: die Query muss in die URL. RFC 9110 empfiehlt eine URL-Länge von unter 8.000 Oktett - bei komplexen Filterstrukturen, verschachtelten GraphQL-Queries oder personalisierten Suchanfragen ist das schnell zu wenig. Außerdem landen Query-Parameter in Logs, Proxy-Protokollen und Browser-Historien. Für sensible Filterparameter keine gute Eigenschaft.

POST löst das URL-Problem: der Payload geht in den Body, beliebig groß, kein URL-Limit. Aber POST ist semantisch nicht safe und nicht idempotent - der HTTP-Layer kann nicht wissen, ob ein wiederholter POST harmlos ist oder einen State-Change auslöst. Die Konsequenz: CDNs und Edge-Proxies cachen POST nicht. Genau deshalb schlägt heute fast jede GraphQL-Query am CDN vorbei direkt auf den Origin durch. Persisted Queries, Query-Hashing, CDN-Bypässe - das sind alles Workarounds für dieses fundamentale Mismatch. Warum sich solche Workarounds über die Zeit zu echten Kosten summieren, habe ich im Composable-Reality-Check ausgeführt.

Was QUERY anders macht

RFC 10008 schließt diese Lücke mit einer neuen HTTP-Methode, die beide Eigenschaften vereint. Die formale Definition (Abstract, §2, Tabelle 1 des RFC):

• Payload im Body - wie POST, kein URL-Limit, kein URL-Leakage
• Explizit safe - QUERY hat keinen Seiteneffekt, der Server darf das als Garantie annehmen
• Explizit idempotent - ein HTTP-Client, ein Proxy oder ein CDN darf QUERY-Requests gefahrlos wiederholen

Das ist keine semantische Feinheit. Es ist die Grundlage, auf der CDNs und Edge-Caches Caching-Entscheidungen treffen. Mit QUERY können komplexe Suchanfragen und Filterqueries wieder am Edge gecacht werden - der Cache-Key schließt den Request-Body und Request-Metadaten ein (§2.7). Origin-Last sinkt, Latenz sinkt, Storefronts werden schneller ohne Änderung am Business-Logic-Layer.

Zusätzlich führt RFC 10008 das Header-Feld Accept-Query ein (§3). Es macht maschinell auffindbar, welche Query-Formate ein Endpoint unterstützt - eine saubere Grundlage für Format-Discovery statt hardcodierter Client-Annahmen.

Ein wichtiger Hinweis zur CORS-Seite: weil QUERY nicht in der CORS-safelist-Methoden-Liste des WHATWG Fetch-Standards steht, löst es einen Preflight-Request aus (§4 Security Considerations). Das ist kein Bug, sondern die erwartete Konsequenz einer neuen Methode. Browser-seitig muss das berücksichtigt werden.

Ehrlich über den Adoptionsweg

GraphQL-over-QUERY ist nicht Teil des RFC und noch nicht standardisiert. RFC 10008 definiert die Methode, nicht die Payload-Formate. Ob und wie GraphQL-Clients QUERY adopten, wird eine separate Diskussion. Ich erwähne es hier, weil das mittelfristig Persisted-Query-Workarounds überflüssig machen könnte - als Möglichkeit, nicht als Versprechen.

Und selbst wenn Clients bereit sind: Server, CDNs, Reverse Proxies und Browser müssen QUERY erst unterstützen, bevor der Standard in Produktion sinnvoll nutzbar ist. Das ist ein Mehrjahres-Weg. Wer jetzt darüber schreibt, tut es nicht, weil QUERY morgen production-ready ist. Wir tun es, weil der Zeitpunkt, an dem Standards gebaut sind, nicht der richtige ist, um anfangen zu denken.

Warum das eine strategische Frage ist - nicht nur eine technische

Hier wird es interessant, und hier ist der Punkt, an dem mir die Architektur-Entscheidung, die wir bei Laioutr getroffen haben, wichtig erscheint.

Wer ein headless Frontend als Individual-Software gebaut hat - ein eigenes Next.js-Projekt, eine Nuxt-App, einen eigenen API-Layer - muss QUERY in jeder Storefront einzeln nachziehen. Transport-Layer anfassen. Caching-Logik neu denken. CORS und Preflight-Handling. Retry-Strategien. Cache-Keys konfigurieren. Alles testen. Pro Projekt. Wieder und wieder, für jeden Kunden, für jede Storefront.

Das ist nicht ein technisches Problem, das einmal gelöst wird. Es ist ein Multiplikationsproblem: so viele Projekte wie Storefronts.

Wer auf einer Plattform baut, hat eine andere Ausgangslage. Bei Laioutr abstrahieren wir die Daten- und Transport-Schicht. Unsere Kunden komponieren Sections und Blocks - sie verdrahten keine HTTP-Calls von Hand. Die Plattform besitzt die Schicht, in der QUERY relevant wird.

Was das bedeutet: Sobald das Ökosystem so weit ist - Servers, CDNs, Browser, GraphQL-Clients - , können wir den Standard zentral einziehen. Jede Storefront auf Laioutr profitiert davon, ohne dass ein einziger Kunde seinen Code anfasst. Keine 50 parallelen Migrations-Tickets. Keine Divergenz zwischen älteren und neueren Projekten. Es ist dieselbe Logik, mit der wir einen Vendor-Wechsel ohne komplettes Replatforming möglich machen - die Plattform absorbiert den Change, nicht der Kunde.

Wir bereiten die Plattform heute schon darauf vor. Nicht weil QUERY morgen live geht, sondern weil Architektur-Entscheidungen, die später elastisch sein sollen, früh getroffen werden müssen.

Was das für dich bedeutet - heute

Wenn du headless baust und auf Individual-Software setzt, ist RFC 10008 heute kein operativer Handlungsbedarf. Aber es ist ein guter Moment, zwei Fragen zu stellen:

Erste Frage: Wer in deiner Architektur besitzt den Transport-Layer? Wenn die Antwort "wir selbst - pro Projekt" ist, dann ist das ein Hinweis auf die Art von Aufwänden, die Protocol-Shifts wie dieser mit sich bringen werden. Frontend-Unabhängigkeit wird genau aus solchen Gründen zum Buying-Criterion - mehr dazu in unserem Wochen-Wrap.

Zweite Frage: Welche deiner heutigen Workarounds - Persisted Queries, Query-Hashing, CDN-Bypässe - lösen eigentlich ein Problem, das sich mit einem saubereren HTTP-Fundament von selbst erledigt?

Eine Frontend-Management-Plattform ist nicht dafür da, dir diese Fragen wegzunehmen. Sie ist dafür da, dass du deine Antworten auf sie nicht in Transport-Layer-Code gießen musst.

RFC 10008 ist veröffentlicht: https://www.rfc-editor.org/rfc/rfc10008.html. Autoren: J. Reschke (greenbytes), J. M. Snell (Cloudflare), M. Bishop (Akamai). Standards Track, Juni 2026.

Wenn ihr headless baut und wissen wollt, was QUERY konkret für eure Architektur bedeutet - schreibt mir oder bucht eine Demo.

Auf einem frontend-unabhängigen Fundament bauen

Composable Headless Frontend · Performance & Core Web Vitals · Agentic Frontend Management Platform

Häufige Fragen zu RFC 10008

Was ist RFC 10008?

RFC 10008 standardisiert die HTTP-Methode QUERY: eine Request-Methode, die wie GET sicher und idempotent ist, aber wie POST einen Request-Body tragen kann. Sie schließt die alte Lücke zwischen GET (kein Body, begrenzte URL-Länge) und POST (Body, aber nicht sicher, idempotent oder cachebar).

Was ändert die HTTP-Methode QUERY für Headless-Frontends?

Ein Storefront kann komplexe Such-, Filter- und GraphQL-artige Anfragen im Request-Body senden, während die Antwort cachebar und idempotent bleibt. Für Product-Listing-Pages, Faceted Search und Search-as-a-Service bedeutet das CDN-Caching, das POST nie liefern konnte, ohne den Zustand in immer längere URLs zu pressen.

Ist HTTP QUERY dasselbe wie GraphQL über GET?

Nein. GraphQL über GET funktioniert nur für kleine Queries, weil die gesamte Query in die URL passen muss und URL-Längen-Limits schnell erreicht sind. HTTP QUERY trägt die Query im Body ohne praktisches Größenlimit und ist als sicher und idempotent definiert, sodass Intermediaries und CDNs die Antwort cachen dürfen.

Wann können wir RFC 10008 produktiv nutzen?

Die Adoption hängt vom Rollout der Client-, Server- und CDN-Unterstützung ab. Der pragmatische Weg heute ist Feature-Detection mit POST-Fallback: HTTP QUERY dort nutzen, wo die ganze Kette es unterstützt, sonst auf POST zurückfallen, damit nichts bricht.