In June 2026 the IETF published RFC 10008, The HTTP QUERY Method, as a Proposed Standard. It closes a hole that has been sitting in HTTP for as long as most of us have been writing against it, and if you have ever built a search endpoint you have already worked around that hole, probably without thinking of it as a workaround.
The gap
HTTP gives you two realistic options for asking a server a question. GET is safe and idempotent: it promises no side effects, so a proxy can cache it, a browser can prefetch it, and a client can retry it after a dropped connection without wondering what it just did twice. What GET cannot reliably do is carry a body. A request body on GET has no defined semantics, and intermediaries are free to drop it.
POST carries whatever body you want. What POST does not carry is any promise. It is neither safe nor idempotent, so nothing downstream can cache it and nothing can safely retry it. The method itself is telling every intermediary on the path: assume this changed something.
So the moment your query outgrows a URL, you are forced to choose between a body and a promise. Everyone picks the body, POSTs the filter payload, and quietly gives up caching and retry safety for what is, semantically, a read.
Where this actually bites
I hit this on a news platform with faceted filtering: readers narrow a feed by campus type, division, district, section, date range. Serialise all of that into a query string and you are one multi-select away from an unreasonable URL. Practical limits vary by server and proxy rather than by spec, but you find the ceiling faster than you expect, and you find it in production.
The second problem is quieter. Query strings end up in access logs, in referrer headers, in analytics, in your reverse proxy's log rotation. Anything sensitive in a filter is now written to disk in five places you did not plan for. Moving it into a body is the correct instinct; losing idempotency to do it is the tax.
What QUERY does
QUERY asks the target to process the enclosed content in a safe and idempotent manner and respond with the result. It carries a body like POST, and it keeps the promises of GET. It is registered in the IANA HTTP Method Registry as safe and idempotent, which means intermediaries can treat it accordingly rather than guessing.
QUERY /feed HTTP/1.1
Host: example.com
Content-Type: application/json
Accept: application/json
{
"campus_type": ["public-university", "medical-college"],
"district": ["tangail", "rangpur"],
"sections": ["admission", "results"],
"published_after": "2026-01-01"
}Caching is the interesting part
Responses to QUERY are cacheable, but the cache key has to incorporate the request content, not just the URL. That is a genuine change in posture. Every cache you have ever configured assumes the URL plus a few headers identify the response; here the body is part of the identity. The spec allows caches to normalise semantically insignificant differences, which matters more than it sounds: two JSON bodies that differ only in key order or whitespace describe the same query, and a cache that treats them as distinct will have a hit rate of roughly zero.
RFC 10008 also gives servers two ways to hand back a URI for the result. Content-Location identifies the specific result of this query. Location identifies a resource that will return the same results from a plain GET. That second one is the useful trick: it lets you accept a large query by body and then hand the client a stable, linkable, cacheable, GET-able address for it.
What I would not do yet
Proposed Standard is the beginning of adoption, not the end of it. A new method has to survive every hop between your client and your server, and the honest failure mode is an intermediary that has never heard of QUERY and rejects or mangles it. Before it reaches your application it passes your CDN, possibly a reverse proxy, possibly a corporate middlebox you will never see.
- Do not rip out working POST search endpoints. There is no prize for being early here, and the failure is invisible to you and visible to your users.
- If you want to adopt it, add QUERY alongside POST rather than in place of it, and keep the POST path as the fallback.
- Check your own edge first. A method your reverse proxy silently drops is a bug you will debug from the wrong end.
- If you build a cache in front of it, decide your body-normalisation rule deliberately. Canonicalise before hashing, or accept that you built a cache that never hits.
- The Location trick is available today in spirit: accept a big filter, persist it, redirect to a short stable URL. That pattern predates the RFC and still works.
The reason this matters beyond the novelty is that it removes a place where we routinely lie to the network. A search POST tells every cache and proxy on the path that state changed, every single time, when nothing changed at all. QUERY lets the request say what it actually is. Infrastructure gets to be helpful again.