What is the HTTP QUERY method?

HTTP QUERY is a new HTTP method defined in RFC 10008, published by the IETF in June 2026. It lets you send query data in a request body like POST, while retaining GET's safe, idempotent, and cacheable semantics. It's the first new general-purpose HTTP read method since PATCH was standardized in 2010.

What's the difference between HTTP QUERY and GET or POST?

GET puts query data in the URL, which has unpredictable length limits across intermediaries and leaks sensitive data into server logs. POST carries a body but has no safe or idempotent semantics, so caches ignore it and retry logic can't safely re-fire it. QUERY combines GET's semantics with POST's body support.

Which frameworks and tools support HTTP QUERY in 2026?

Node.js has parsed QUERY natively since early 2024. OpenAPI 3.2 documents it. Spring support is not yet shipped as of July 2026. Browsers are still evaluating, with an active WHATWG proposal for form support. Cloudflare and Akamai co-authored the RFC, so CDN-level support may arrive soon.

Are there security concerns with the HTTP QUERY method?

QUERY is not CORS-safelisted, so browsers trigger a preflight. Older WAFs and proxies may reject it or handle it without your normal read-traffic rules. Cache implementations that don't correctly include the request body in the cache key can introduce cache poisoning or cache deception vulnerabilities.

HTTP Gets a New Method: QUERY Is Now a Standard

HTTP just got its first new general-purpose read method since PATCH in 2010. The IETF published RFC 10008 on June 15, 2026, defining a new HTTP method called QUERY. It does what GET and POST have both failed to do cleanly for 25 years: send structured query data in a request body with full safe, idempotent, cacheable semantics.

If you build search APIs, GraphQL endpoints, analytics dashboards, or anything with complex filter payloads, this one matters.

The Problem It Fixes

GET is safe, idempotent, and cacheable. But query parameters live in the URL, and URL length limits vary unpredictably across proxies and intermediaries. RFC 9110 only guarantees 8,000 octets as a minimum floor. Beyond that, you get a 414 URI Too Long. Complex filter objects also become unreadable URL-encoded strings, and request URIs are far more likely to show up in server logs than request bodies — a real problem when your query contains sensitive data.

POST carries a body and has no size limit, but it has no safe or idempotent semantics. Caches ignore it. Retry logic can't safely re-fire it. Nothing in the protocol tells a gateway, WAF, or CDN that a POST /search is read-only — so the ecosystem treats it like a write, because that's all it knows.

QUERY takes the body support from POST and the safe/idempotent/cacheable semantics from GET. That's the entire pitch, and it's the right one.

What It Looks Like

A basic QUERY request looks like this:

QUERY /users HTTP/1.1 Host: example.org Content-Type: application/json { "role": "admin", "sort": "name", "page": 1 }

Servers advertise which content types they accept via a new response header, Accept-Query. The RFC's own examples cover application/x-www-form-urlencoded, application/sql, application/jsonpath, and application/xslt+xml — QUERY is content-type agnostic by design.

Responses are cacheable, and the cache key includes both the URI and the request body. The RFC also defines a Location header pointing at a repeatable query URI when the server wants to make a specific query directly addressable.

What the Semantics Actually Buy You

Safe and idempotent aren't just documentation — they're protocol-level guarantees registered with IANA. That means clients can retry QUERY automatically on timeout without fear of duplicate writes. Load balancers can route it differently from POST. WAFs and rate limiters can distinguish reads from writes at the method level, not by parsing the path.

For GraphQL specifically: queries are safe and idempotent by design, but they often exceed URL limits when sent via GET. The community has been using POST as a workaround since GraphQL launched. QUERY is the semantically correct method for the operation, and it finally exists.

Support Status in July 2026

Node.js has parsed QUERY at the HTTP layer since early 2024, so a plain Node HTTP server handles it today with no changes. OpenAPI 3.2 documents it. Spring has not shipped support as of this writing. Browsers are still evaluating — there's an active WHATWG proposal for HTML form method="query" support, but no browser has shipped it yet.

Cloudflare and Akamai are co-authors of RFC 10008, which is a meaningful signal. CDN-level support typically tracks author commitment, so edge recognition may arrive before framework integrations do. Watch for curl, browser fetch(), and your framework of choice to announce support.

The security surface is worth noting: QUERY is not a CORS-safelisted method, so browser JavaScript triggers a preflight. Older WAFs and proxies may reject an unrecognized method or route it as a passthrough without applying your normal read-traffic rules. And caches that hash the body incorrectly open up cache poisoning and cache deception vectors — check your CDN's handling before you rely on caching for QUERY responses.

How to Roll It Out

Don't replace your existing endpoints yet. Add QUERY alongside a POST-based search endpoint, advertise it via Accept-Query, and let clients migrate as their tooling supports it. For server-side applications where you control the full stack end to end, you can start using QUERY today. For public APIs with clients you don't control, wait until browser and intermediary support catches up — good ideas in HTTP specs sometimes take years.

Sources: IETF RFC 10008, eCorpIT, Hive Security