HTTP finally has a QUERY method. I spent an hour finding out what works today

I have built more search endpoints than I can count. Candidate search in a recruitment platform, dealer listing filters with saved searches in a vehicle marketplace, telemetry queries in an IoT dashboard. And every single time, the same uncomfortable choice comes up at design time, and every time there are exactly three bad options.

Option one: GET with a query string. Works great until the filter object grows. A saved search with fifteen filters, sort orders and pagination does not belong in a URL. You hit length limits, you fight encoding, and the whole thing ends up in access logs.

Option two: GET with a body. Elasticsearch made this famous, and it has been making people miserable ever since. The old HTTP specs never said what a GET body means, so clients, proxies and load balancers each picked their own behavior - some drop it, some forward it, some reject the request outright. You cannot build on semantics nobody agreed on.

Option three: POST /search. This is what I have done for years, like almost everyone. It works. It is also a small lie. A search is safe and repeatable - it changes nothing on the server - but POST tells every intermediary the opposite. No shared caching. No automatic retry on a dropped connection, because a proxy has to assume a POST might have side effects. You give up real, useful HTTP behavior just to be allowed to send a body.

Last month this stopped being a "pick your poison" situation. RFC 10008, published June 2026 after fourteen draft revisions, defines the QUERY method: a request with a body, like POST, but explicitly safe and idempotent, like GET - and with cacheable responses. It is precisely the missing verb for "here is a complex description of what I want; this changes nothing".

QUERY /vehicles HTTP/1.1
Content-Type: application/json

{ "filters": { "fuel": "ev", "battery_health_min": 85 },
  "sort": "price_asc", "page": 3 }

What actually works today

Reading about a new RFC is one thing. I wanted to know what happens when you actually send a QUERY request in 2026, so I spent an hour finding out. Everything below is a real result from my machine, not from documentation.

Node.js 24: works out of the box. http.METHODS includes QUERY as a first-class method, and a plain http.createServer receives it like any other request:

// server logs: { method: 'QUERY', receivedBody: '{"filter":{"status":"active"}}' }
const server = http.createServer((req, res) => { /* req.method === 'QUERY' */ });

fetch: works. Node's built-in fetch (undici) sends method: 'QUERY' with a body without complaint. The fetch spec only forbids CONNECT, TRACE and TRACK, so QUERY passes - though I have only verified server-side fetch, not every browser, so treat browser support as "test before you rely on it".

curl: works, since a custom method is just curl -X QUERY --data ....

Cloudflare: passes it through. I sent a QUERY request to this very site, which runs on a Cloudflare Worker serving static assets. The response was a clean 405 Method Not Allowed - meaning the edge did not choke on the method; it delivered it to the handler, and the handler correctly said "static files don't do that". For a brand-new verb, the method traveling untouched through a major CDN is the important part.

ASP.NET Core: there is no MapQuery() helper yet, but routing has always supported custom methods, so endpoints.MapMethods("/search", ["QUERY"], handler) routes it today.

Would I use it in production?

On a public API, not yet. The RFC is a month old; API gateways, WAF rules, OpenAPI tooling and client SDK generators all need time, and a search endpoint that some corporate proxy silently mangles is worse than an honest POST.

But on internal APIs - service-to-service, admin panels, anything where I control both ends - I intend to start now. The retry semantics alone are worth it: an idempotent search can be safely retried by infrastructure when a connection drops, which is exactly the kind of resilience you otherwise have to build by hand. My plan is to introduce it on an internal admin search endpoint first and let it earn its way outward.

Twenty-five years of POST /search was a workaround. It is nice to finally have the real verb.