HTTP gets a QUERY method: GET with a body, because firewalls strip GET bodies

What QUERY is, in one line

The explainer puts it simply: QUERY is similar to GET, but with a request body, and it's meant to be safe and idempotent. That combination is the whole point. GET can technically carry a body, but per RFC 9110 that content "has no generally defined semantics" and a client "SHOULD NOT" send it — so clients, proxies and servers handle it inconsistently. POST allows a body but is non-idempotent and signals "create or modify," which is wrong for a read.

QUERY fills the gap: a read operation that needs structured input. The motivating pains are familiar — complex filters create massive unreadable URLs that hit length limits, special characters bloat the request, and query strings get logged. A QUERY request can be cached, the spec notes, but implementations must fold the request body into the cache key.

"Just standardize GET with a body" vs. the reason that won't work

The thread's central fight was whether a whole new verb was even necessary. The minimalist case was clean:

"I still don't get the need for QUERY. One can create a search or filter resource with a POST request and then query it using GET." — nesarkvechnep

The sharpest version of the skeptic argument conceded the new method works but questioned the motive:

"specifying this behavior would get you in the same situation as adding a new method… The only benefit of adding a new method is for marketing/awareness… most of enterprise stuff (WAF, frameworks, etc.) are not going to work overnight" — stymaar

Then the people who'd actually been burned answered, and they were specific. The "just use GET with a body" advice collapses against real infrastructure:

"We had to change our app when we took on a client with a strictly configured WAF which rejected GET with body." — jefc1111, who hit a client's WAF in production

"Some API gateways outright strip request bodies from GET requests to prevent them from being forwarded." — locknitpicker

Another pointed at the canonical proof: browser fetch won't even let you put a body on a GET, citing the open WHATWG fetch issue. A distinct verb that old systems don't recognize is, the argument goes, the only thing that actually forces an upgrade path — and 405 Method Not Allowed gives a clean fallback to POST.

The caching trick that justifies the new verb

The most substantive defense explained what QUERY buys you that POST can't. A QUERY can return a Location header pointing at a GET-addressable resource, and — crucially — the browser and middleboxes can treat that as a repeatable mapping:

"A POST can return Content-Location… but the browser can't assume that the same POST body contents create the same result… whereas the QUERY Location represents the QUERY itself as a repeatable object." — WorldMaker, walking through the caching semantics

That's the line between marketing and mechanism: because QUERY is defined as safe and idempotent, a cache can key on the body and a client can safely retry — properties POST can never advertise. The honest read is the explainer's own caveat, echoed in the thread: don't reach for QUERY on shareable or bookmarkable links yet, and expect the same multi-year wait for middleboxes that every HTTP feature endures. GraphQL, which today tunnels every read through POST, is the obvious early adopter — queries on QUERY, mutations on POST.