HTTP QUERY has an RFC but almost no implementations

HTTP has a new method for searching. The IETF published RFC 10008, "The HTTP QUERY Method", in June 2026 as a Proposed Standard from the httpbis Working Group. Three months on, InfoQ reported in September 2026 that no project has announced a completed production deployment of it.

The method was written by Julian Reschke, James M. Snell and Mike Bishop. It exists to solve a problem every API developer has worked around at least once.

The gap between GET and POST

A search request wants two things at the same time, and until now HTTP made you pick one.

GET is safe, meaning it does not change anything on the server. It is idempotent, so a client can retry it without consequence, and it is cacheable. The catch is that everything you are asking for has to fit in the URL. Long filters hit length limits, they land in server access logs, and nested structures are awkward to encode.

POST carries a body of any size and shape. But it is defined as neither safe nor idempotent, so caches skip it, clients cannot safely retry it, and anything in between has to assume it changed something.

QUERY takes the useful half of each. The RFC defines it so that "the request target process the enclosed content in a safe and idempotent manner" and then respond with the result. It is safe, idempotent and cacheable, and it carries a request body. The RFC describes the case it is for as one where "the data conveyed is too voluminous to be encoded in the request's URI."

A few rules come with it. Content-Type is mandatory: "Servers MUST fail the request if the Content-Type request field ... is missing or is inconsistent with the request content." A server can advertise which query formats it accepts through an Accept-Query header. Conditional requests work with the standard HTTP validation headers.

Caching is the part to get right

Making a method with a body cacheable is the hard problem the RFC has to solve. A cache normally keys on the URL, and a QUERY request's meaning lives in its body.

RFC 10008's answer is that cache keys must incorporate the full request content along with the related metadata. A cache that ignores the body would serve one search's results for a different search.

The RFC also lets a server hand back a URL for the result instead. It can assign a URI to the results and point at it with Content-Location or Location, or use a 303 redirect when the processing happens indirectly. That gives clients a plain GET they can share, bookmark and cache normally.

Security cuts both ways here. Moving a query out of the URL and into the body is a privacy improvement, because the RFC notes a URI "is more likely to be logged" than request content. But the escape hatch above can undo it. The spec says a result URI "SHOULD be chosen such that it does not include any sensitive portions" of the original query. Browsers add one more constraint: QUERY is not a safelisted method, so cross-origin requests trigger a CORS preflight.

Who has actually shipped it

This is where the standard stands apart from the practice. InfoQ lists the state of support as tracked work, not finished work.

Project	Status, per InfoQ
Rust http crate	Support merged
.NET	Issue tracked
Axum	Issue tracked
Quarkus	Issue tracked
Bruno	Issue tracked

None of these carries an announced production deployment date. InfoQ's assessment is that "real adoption will likely be measured in years," because a method only becomes usable once clients, servers, proxies and caches along the path all understand it. It frames QUERY as an optional addition rather than a replacement for GET or POST.

What this means for developers

Do not rewrite your search endpoints. A QUERY request that meets an intermediary which does not know the method simply fails. You do not control every hop between your client and your server.

The useful move today is smaller: recognize which of your endpoints is a QUERY in disguise. A POST /search that changes nothing on the server is the pattern this method exists for. Knowing that costs nothing now and makes the eventual migration a rename rather than a redesign.

If you maintain a client library, a server framework, a proxy or a cache, the calculation is different, because you are the bottleneck the adoption timeline is describing. The RFC's cache-key requirement is the part most likely to be implemented wrong, and getting it wrong means serving one user's search results to another.

One caution on the safety claim. QUERY being safe and idempotent is a promise your handler has to keep, not something the method enforces. Nothing stops a server from mutating state inside a QUERY handler. If it does, every retry and every cache along the path becomes a bug that is hard to find.