RFC 10008: The New HTTP Method That Makes You Rethink Headless Storefronts

In June 2026, the IETF published a new HTTP standard that almost nobody in commerce frontend circles is talking about. RFC 10008 defines a new HTTP method: QUERY. That sounds unspectacular. I think it is not.

The problem QUERY solves

Every headless frontend lives on queries. Search, faceted filtering, product listings, GraphQL queries, personalisation - all of these are, at their core, structured requests to a data endpoint. Until now, we had exactly two options for that, and both are unsatisfying.

GET is semantically the right choice: cacheable, safe (does not trigger a state change), idempotent (safe to repeat automatically). But the query must live in the URL. RFC 9110 recommends staying under 8,000 octets in URL length - with complex filter structures, nested GraphQL queries, or personalised search requests, that ceiling arrives quickly. Beyond that, query parameters end up in logs, proxy records, and browser history. Not ideal for parameters that carry any degree of sensitivity.

POST solves the URL problem: the payload goes in the body, arbitrarily large, no URL limit. But POST is semantically neither safe nor idempotent - the HTTP layer cannot know whether a repeated POST is harmless or triggers a state change. The consequence: CDNs and edge proxies do not cache POST. This is exactly why almost every GraphQL query today bypasses the CDN and hits the origin directly. Persisted queries, query hashing, CDN workarounds - these are all patches for this fundamental mismatch. I've written about why workarounds like these compound into real cost over time in our composable reality check.

What QUERY does differently

RFC 10008 closes this gap with a new HTTP method that combines both properties. The formal definition (Abstract, §2, Table 1 of the RFC):

• Payload in the body - like POST, no URL limit, no URL leakage
• Explicitly safe - QUERY has no side effect; the server may treat that as a guarantee
• Explicitly idempotent - an HTTP client, proxy, or CDN may repeat QUERY requests without risk

This is not a semantic subtlety. It is the foundation on which CDNs and edge caches make caching decisions. With QUERY, complex search requests and filter queries can once again be cached at the edge - the cache key includes the request body and request metadata (§2.7). Origin load decreases, latency decreases, storefronts become faster without any change to the business logic layer.

RFC 10008 also introduces the Accept-Query header field (§3). It makes it machine-discoverable which query formats an endpoint supports - a clean basis for format discovery instead of hardcoded client assumptions.

One important note on the CORS side: because QUERY is not on the CORS safelist of methods in the WHATWG Fetch standard, it triggers a preflight request (§4 Security Considerations). That is not a bug; it is the expected consequence of a new method. This needs to be accounted for on the browser side.

Being honest about the adoption path

GraphQL-over-QUERY is not part of RFC 10008 and has not been standardised. RFC 10008 defines the method, not the payload formats. Whether and how GraphQL clients adopt QUERY will be a separate discussion. I mention it here because it could, in the medium term, make persisted query workarounds unnecessary - as a possibility, not a promise.

And even when clients are ready: servers, CDNs, reverse proxies, and browsers all need to support QUERY before the standard is usable in production in a meaningful way. This is a multi-year road. Writing about it now is not because QUERY is production-ready tomorrow. It is because the right time to think about a standard is not when it has already shipped everywhere.

Why this is a strategic question - not just a technical one

Here it gets interesting, and here is the point where the architecture decision we made at Laioutr becomes relevant to me.

If you have built a headless frontend as custom software - your own Next.js project, a Nuxt application, your own API layer - you will need to implement QUERY support in every storefront individually. Touch the transport layer. Rethink caching logic. Handle CORS and preflight. Define retry strategies. Configure cache keys. Test everything. Per project. Again and again, for each client, for each storefront.

This is not a technical problem solved once. It is a multiplication problem: as many projects as storefronts.

If you build on a platform, your starting position is different. At Laioutr, we abstract the data and transport layer. Our customers compose sections and blocks - they do not wire HTTP calls by hand. The platform owns the layer where QUERY becomes relevant.

What that means in practice: once the ecosystem is ready - servers, CDNs, browsers, GraphQL clients - we can adopt the standard centrally. Every storefront on Laioutr benefits without a single customer touching their code. No 50 parallel migration tickets. No divergence between older and newer projects. It is the same logic that lets us make switching commerce vendors without a full replatforming possible - the platform absorbs the change, not the customer.

We are preparing the platform for this today. Not because QUERY is going live tomorrow, but because architecture decisions that need to be elastic later have to be made early.

What this means for you - today

If you are building headless on custom software, RFC 10008 is not an operational priority today. But it is a good moment to ask two questions.

First question: Who in your architecture owns the transport layer? If the answer is "we do - per project", that is a signal about the kind of effort protocol shifts like this one will create. Frontend independence is becoming a buying criterion for exactly these reasons - more on that in our weekly wrap.

Second question: Which of your current workarounds - persisted queries, query hashing, CDN bypasses - are actually solving a problem that a cleaner HTTP foundation would remove on its own?

A frontend management platform is not there to take those questions away from you. It is there so that you do not have to encode your answers to them in transport layer code.

RFC 10008 is published: https://www.rfc-editor.org/rfc/rfc10008.html. Authors: J. Reschke (greenbytes), J. M. Snell (Cloudflare), M. Bishop (Akamai). Standards Track, June 2026.

If you are building headless and want to understand what QUERY means concretely for your architecture - write to me or book a demo.

Build on a frontend-independent foundation

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

Frequently asked questions about RFC 10008

What is RFC 10008?

RFC 10008 standardises the HTTP QUERY method: a request method that is safe and idempotent like GET, but can carry a request body like POST. It closes the long-standing gap between GET (no body, limited URL length) and POST (a body, but not safe, idempotent, or cacheable).

What does the HTTP QUERY method change for headless frontends?

It lets a storefront send complex search, filter, and GraphQL-style requests in a request body while the response stays cacheable and idempotent. For product listing pages, faceted search, and search-as-a-service calls, that means CDN-level caching that POST could never deliver, without cramming state into ever-longer URLs.

Is HTTP QUERY the same as sending GraphQL over GET?

No. GraphQL over GET works only for small queries because the whole query has to fit in the URL, and it is easy to exceed URL length limits. HTTP QUERY carries the query in the body with no practical size limit, and it is defined as safe and idempotent, so intermediaries and CDNs may cache the response.

When can we use RFC 10008 in production?

Adoption depends on client, server, and CDN support rolling out across the stack. The pragmatic path today is feature detection with a POST fallback: use HTTP QUERY where the whole chain supports it, and fall back to POST elsewhere, so nothing breaks while support matures.