HTTP finally gets a QUERY method — a safe, cacheable request that carries a body
RFC 10008 standardizes the verb people have been faking for years: a request that's safe and idempotent like GET, but carries its query in the body like POST. The catch surfaced in the thread within minutes — the same idea died once before, killed by middleboxes.
QUERY solves two old annoyances at once: URL query strings have undefined length limits, and POST /search lies about idempotency. The new method is explicitly safe, idempotent, and cacheable, with the request body folded into the cache key.
But an engineer pointed out QUERY has existed in spirit since WebDAV's SEARCH method nearly two decades ago — and what killed it was proxies and WAFs stripping the body off methods they don't recognize. Until gateways catch up, POST stays the pragmatic choice.
What RFC 10008 actually standardizes
RFC 10008, published in 2026 as a Proposed Standard by Julian Reschke, James M. Snell, and Mike Bishop, defines a new HTTP method: QUERY. The one-sentence version from the spec: a QUERY "requests that the request target process the enclosed content in a safe and idempotent manner and then respond with the result of that processing."
It exists to close a gap everyone has worked around. GET puts parameters in the URL, where length limits are undefined and everything ends up in access logs. POST can carry an arbitrarily large body, but it carries no promise of safety — a proxy can't know whether POST /search mutated anything, so it can't be retried or cached. QUERY threads the needle: it is safe and idempotent like GET, so it can be retried freely, and it carries its parameters in the request body like POST. Responses are cacheable, and the cache key must incorporate the request content — caches may normalize semantically insignificant differences before keying.
The working group also explicitly rejected the obvious shortcut. As the RFC explains, GET-with-a-body "was heavily considered by the IETF working group, but it was ultimately rejected in favor of creating the new QUERY method" — down to historical interoperability problems and strict compliance with HTTP's architectural definitions.
The objection that has buried this idea before
The most-upvoted technical comment in the thread wasn't excitement — it was a warning grounded in history:
"QUERY has existed in spirit for nearly two decades as WebDAV's SEARCH method, and the thing that always killed it in practice was intermediaries. Plenty of proxies, WAFs, and load balancers either strip the body from methods they do not recognize or reject the request outright … Until gateway and CDN support is real rather than just on paper, POST with a header marking the body as part of the cache key stays the pragmatic choice." — a commenter citing RFC 5323, WebDAV SEARCH
A second engineer took aim at the caching story itself, calling it the spec's weak point:
"It feels extremely odd to include the request body as part of the cache key. It also implies an unbounded and user-controlled cache key … in a hostile scenario implies cache busting would be trivial." — a commenter walking through the cache-key attack surface
And a simpler design question kept recurring — why a whole new verb at all:
"Wouldn't just putting an etag on POST requests accomplish the same thing? If I'm understanding it the server has to maintain state to ensure idempotency." — a commenter proposing the ETag-on-POST alternative
"I've been sending request bodies with GET for years"
Underneath the skepticism ran a current of relief from people who've been improvising this forever. "I was never a fan of creating POST /search endpoints when working with robust APIs," one wrote. A founder building developer tooling had already been bending the rules:
"I've been sending request body along GET method for years now." — the maintainer of logdy.dev
Another builder reported shipping the QUERY method in production well before it standardized, paired with Range headers for paging: "Wow, it still isn't a standard? I've been building with the QUERY method for years now." Even the name drew a wince — "query" already means an HTTP request in general, and a commenter noted the RFC title alone confused him on first read.
A clean spec waiting on the infrastructure to catch up
The verb is well-defined and solves real problems: query payloads too big for a URL, and reads that today masquerade as POSTs. The thread's verdict is narrower than the RFC's optimism. QUERY will be exactly as useful as the proxies, WAFs, CDNs, and load balancers between client and server decide to let it be — and the last time the industry tried this, those middleboxes won. The spec is the easy part; the deployment is the decade-long part.
Get breakdowns like this every day
The top Hacker News stories, unpacked — by email, Telegram, or RSS.
An essay on the human moat AI can't copy reads like AI wrote it
Chris Hillman argues the one thing AI can't commoditize is genuine human connection: notice, listen, remember, build trust. The first reply in the thread was that the essay reads like it was written by AI.