HTTP QUERY: The First New Method in 16 Years (RFC 10008)

Straight answer: in June 2026 the IETF published RFC 10008, standardizing the QUERY method: safe and idempotent like GET, but able to carry a body like POST, and cacheable — with the cache key including the request content. It's the first genuinely new HTTP method since PATCH (RFC 5789, March 2010): sixteen years. And no, you won't use it next week — server, proxy and client support is still close to nonexistent.

TL;DR

QUERY = GET with a body. Safe, idempotent, cacheable, repeatable with no side effects.
It solves a real problem: complex searches that don't fit in a URL and that you're forced to send as POST today, losing caching and safe retries.
RFC 10008, June 2026, Standards Track. Authors: Julian Reschke (greenbytes), James M. Snell (Cloudflare), Mike Bishop (Akamai).
Two details that change your architecture: the cache key includes the body, and QUERY is not CORS-safelisted (from a browser you always pay for a preflight).
Verdict: design for it, don't deploy it. Realistic adoption is 2027-2028.

The problem QUERY actually solves

If you've ever built a serious search API, you know the fork in the road. You have a complex query — nested filters, arrays of IDs, a geo polygon, a list of facets — and you must choose:

Go with GET and stuff everything into the query string. That works until you hit URL length limits: the standard doesn't set one, but in practice servers stop around 8,000 characters (and some proxies far earlier). On top of that, every parameter lands in web server logs, browser history, the Referer header and half a dozen monitoring systems. If those filters contain an email or a tax ID, you've just scattered it across five places.

Go with POST and the size problem disappears, but you lose three things at once: caching (POST is cacheable in theory, never in practice), idempotency (a proxy or client can't know whether retrying is safe) and semantics (you're telling the world "this request changes state" when you're only reading).

For twenty years the answer has been "use POST and stop thinking about it". QUERY is how you stop lying to the protocol.

GET vs POST vs QUERY

Property	GET	POST	QUERY
Safe (no state change)	Yes	No	Yes
Idempotent	Yes	No	Yes
Request body	No	Yes	Yes
Cacheable	Yes	In theory, never in practice	Yes (key = body)
Automatically retryable	Yes	Risky	Yes
Sensitive data in URL	Yes, sadly	No	No

What a QUERY request looks like

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

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

The RFC doesn't mandate a body format: the Content-Type and its media type define what the query means. Send JSON, something SQL-like, GraphQL, CQL — whatever your server understands. The server must reject requests with no Content-Type or with inconsistent metadata.

To be discoverable, a server advertises support through the Accept-Query response header, listing the media types it accepts for that resource. That's the discovery mechanism: before firing a QUERY, a well-behaved client already knows whether it's worth it.

The two details that change your architecture

1. The cache key includes the body

This is the interesting part, and the treacherous one. The RFC states that a QUERY response is cacheable and that the cache key MUST incorporate the request content. On paper it's wonderful: you can finally put a CDN in front of a complex search.

In practice, every intermediary has to hash the body and — to be efficient — normalize it: two identical JSON documents with keys in a different order are the same query but different bytes. The RFC allows normalization (content-encoding based or format-specific) and its Security Considerations flag the flip side: a cache that normalizes incorrectly returns the wrong response to someone else. Silent cache poisoning, with another user's data. Exactly the kind of thing that makes you cautious.

2. From the browser, you always pay the preflight

QUERY is not a CORS-safelisted method. Translation: any cross-origin fetch() using QUERY triggers an OPTIONS preflight before the real request. Two round-trips instead of one, and an Access-Control-Allow-Methods to configure properly. Not dramatic — but budget for it if you're eyeing QUERY for the frontend.

My favorite part: the query gets a URL

There's a piece of RFC 10008 that goes unnoticed and is the real gift. The server can respond with a Location header assigning a URI to that specific query. From then on, the complex search you just ran has an address: bookmark it, send it to a colleague, re-run it nightly from a cron to see how the results changed.

That's the thing POST could never give you and GET could never afford. With 301 or 308 the server can also tell you that the query permanently lives somewhere else.

Would I run it in production today?

No. And I say that as someone who genuinely enjoys new standards.

Real support is embryonic: few application servers implement QUERY natively, middleware and frameworks treat it as an unknown method, and above all the infrastructure in between — corporate load balancers, WAFs, proxies, legacy API gateways — tends to block or rewrite verbs it doesn't recognize. The adoption bottleneck won't be your backend: it'll be the three hops you don't control. The reasonable community estimate is 2027-2028 for support broad enough to rely on.

Meanwhile, the sensible move is the one I'd recommend to any team I work with:

Design your search APIs as if QUERY already existed. Dedicated endpoint, declarative query in the body, no side effects, deterministic results.
Expose that endpoint as POST today, but treat it internally as safe and idempotent: no writes, no counters, no side effects.
When the infrastructure catches up, adding the QUERY verb is one routing line, not a refactor.

Same principle as keeping discipline when nobody rewards it yet: the bill arrives later, and it's bigger.

FAQ

Does QUERY replace GET?

No. GET remains the method for retrieving a resource identified by its URL, and it's irreplaceable for anything that must be linkable and trivially cacheable. QUERY is for requests too large, too structured or too sensitive to live in a URL.

Can I already use it with fetch() in the browser?

Technically fetch('/orders', { method: 'QUERY', body }) is a valid call, but the server on the other end has to understand it and the browser will run a CORS preflight cross-origin. Until there's server-side support along the whole proxy chain, it stays a lab experiment.

Why did a new method take 16 years?

Because adding a verb to HTTP means convincing browsers, servers, CDNs, proxies, firewalls and billions of lines of existing code. PATCH (2010) took years to become normal. QUERY starts with the same problem: the spec is the easy part, the ecosystem is the hard one.

Is QUERY more secure than GET?

For sensitive data, yes — and the RFC says so explicitly: URIs are far more likely to be logged and processed by intermediaries than request content. Moving filters from the query string into the body keeps them out of logs, history and Referer. It isn't encryption — it's just no longer writing them in the clear in five places.

If you're designing or rebuilding a product's APIs and want them to hold up for the next five years (new standards included), let's talk — it's a good chunk of what I do as a Fractional CTO.