HTTP QUERY: The New Method for Safe Queries

The HTTP QUERY method is the long-awaited answer to an old problem: safe, idempotent lookups with a real request body. Since June 2026 it has been an official standard as RFC 10008 and is registered with IANA, so it is no longer a mere draft. In practice, browser support is still missing, which is why it shines today mainly for server-to-server communication.

What's the deal? 🧐

The HTTP QUERY method is a new HTTP method that finally combines what GET and POST never cleanly brought together: it is safe and idempotent like GET, yet it may carry a request body like POST. That closes exactly the gap we have been papering over with workarounds for years.

The typical use case is the classic lookup: complex filters, search requests, GraphQL queries or structured conditions that grow too large for the URL. Until now that left only a choice between two bad options. QUERY cleans this up.

The problem: GET is too short, POST lies 🤔

Let's look at how we handle lookups today. With a GET request, every parameter sits in the URL, after the question mark as a query string. That is clean, cacheable and idempotent, but the URL length is limited. HTTP itself defines no hard limit, yet many servers and proxies cut off around 8 KB (RFC 9110 recommends supporting at least 8,000 octets). A nested filter or a long list of IDs blows past that quickly.

So we reach for POST. The body can be any size, and the URL-length problem is gone. But POST is a small semantic lie: by specification it is neither safe nor idempotent nor sensibly cacheable. We tell the server and every intermediary „something is changing here", even though we only want to read. Caches, retries and monitoring read that the wrong way, and we throw away every optimization built on safety and idempotency.

What the HTTP QUERY method does differently 📦

QUERY takes the best of both worlds. The request carries its content in the body, like POST, but the semantics are those of GET. The specification puts it this way:

„A QUERY request asks the request target to process the enclosed content in a safe and idempotent manner and then respond with the result of that processing."

The body defines the query, and the Content-Type describes its format. Important: the server must reject the request if the Content-Type is missing or inconsistent with the content. That splits the properties cleanly:

Property	GET	QUERY	POST
Safe	yes	yes	potentially no
Idempotent	yes	yes	potentially no
Cacheable	yes	yes	limited
Request body	no	yes	yes

HTTP request methods - MDN Web Docs

Referenz aller HTTP-Methoden mit ihren Eigenschaften: safe, idempotent und cacheable.

MDN Web Docs

A real example 💻

Here is what a QUERY request looks like, a contact search taken straight from RFC 10008:

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=%22email=@example.%22

And the response, plain old JSON:

HTTP/1.1 200 OK
Content-Type: application/json

[
  { "surname": "Smith",
    "givenname": "John",
    "email": "[email protected]" }
]

The charm lives in the body: it can be arbitrarily complex. A GraphQL query, a JSON filter object or a SQL-like expression all fit in here without bloating the URL. That is exactly why QUERY is so interesting for GraphQL-over-HTTP, which today almost always rides on POST.

QUERY vs. POST: the direct comparison ⚖️

Why is QUERY the better choice for lookups than POST, the way it is mostly done today? It comes down to four points that make a real difference in daily work:

Aspect	POST (for reads)	QUERY
Semantics	signals „something changes"	signals „read only"
Idempotency	no, retry is risky	yes, retry is safe
Cacheable	effectively no	yes, cache key includes body
Message to proxies	misleading	correct

In short: POST works for lookups, but it undermines the guarantees the whole HTTP ecosystem is built on. QUERY tells the truth about the request, and caches, proxies, load balancers and retry logic can rely on it. That is the core of it: not a new feature for its own sake, but honest semantics.

Just a draft? No, now RFC 10008 📜

For a long time QUERY really was just that, a draft. The IETF draft was named draft-ietf-httpbis-safe-method-w-body and went through 14 revisions in the httpbis working group. In June 2026 it became RFC 10008 with the status Proposed Standard, written by Julian Reschke, James Snell and Mike Bishop.

RFC 10008: The HTTP QUERY Method

Die offizielle Spezifikation der HTTP QUERY-Methode, Proposed Standard vom Juni 2026.

RFC Editor

IANA has officially added QUERY to the „HTTP Method Registry", marked as safe and idempotent. So it is a fully fledged, standardized HTTP method, no longer an experiment. If you read somewhere that QUERY is „just a draft", that has not been correct since June 2026.

RFC 10008 - The HTTP QUERY Method

Status, Historie und Dokumente zu RFC 10008 auf dem IETF Datatracker.

IETF Datatracker

One catch remains: MDN has not documented the method yet. The corresponding ticket in the MDN content repo was opened only on 8 July 2026. Anyone looking for an official MDN page on QUERY will not find one for now, and the authoritative reference until then is the RFC itself.

Add HTTP QUERY method Issue #44665 mdn/content

Das offene Ticket, das die noch fehlende MDN-Dokumentation zur QUERY-Methode nachfordert.

GitHub

Can I use this today? 🛠️

Sort of. The specification is done, and the tooling landscape is catching up. The state of things in July 2026:

.NET 10 (LTS) ships full client and server support, including HttpMethod.Query and parsing in the Kestrel server.
Browsers cannot send QUERY from fetch or XHR yet. That is exactly what holds back public web APIs right now.
Proxies and CDNs: Cloudflare and Akamai co-authored the RFC, but they do not reliably cache QUERY responses at scale yet.

In .NET a client call already looks like this today:

using var request = new HttpRequestMessage(HttpMethod.Query,
    "https://api.example.com/products/search")
{
    Content = JsonContent.Create(filter)
};

using var response = await httpClient.SendAsync(request);
var page = await response.Content.ReadFromJsonAsync<ProductPage>();

An important stumbling block for browser use is CORS: a QUERY request with a body and a custom content type triggers a preflight that the server has to answer correctly. If you are not yet comfortable with that topic, it is worth a look first:

My advice: use QUERY today where you control both sides, so server-to-server or between internal microservices. For public APIs serving browsers, it is better to wait until the engines catch up.

Verdict 🚀

QUERY is one of those methods that make you wonder why it was not there all along. It ends the years-long abuse of POST for simple lookups and finally gives us a method that is safe, idempotent and cacheable while still carrying a body.

With RFC 10008 the standard is done and dusted. What is still missing is adoption in browsers and caches, and in my experience that comes with time. If you build APIs, keep QUERY on your radar from now on. Day over, time for a coffee.