RFC 10008: HTTP Gets a Native QUERY Method

Source: IETF HTTP Working Group — RFC 10008 — published June 2026, Proposed Standard (background via Kreya blog, June 17 2026)

Summary

RFC 10008 defines QUERY, a new HTTP method that carries a request body like POST but is explicitly safe, idempotent, and cacheable like GET. It's the first new standard HTTP method registered since PATCH in 2010, authored by Julian Reschke (greenbytes), James M. Snell (Cloudflare), and Mike Bishop (Akamai). It closes a long-standing gap: complex read-only queries (deep filters, large ID lists, nested search criteria) currently either bloat a GET URL past practical length limits or get sent over POST, which lies about intent — POST is defined as non-idempotent, so retries, caches, and proxies can't safely assume it's harmless to repeat.

Key Takeaways

• Semantics, not just syntax: QUERY is defined as safe (no expected state change) and idempotent (safe to retry after a dropped connection) — properties POST explicitly lacks. This is what lets infrastructure (CDNs, proxies, load balancers) treat it like GET for retry/caching logic while still allowing a body.
• Servers MUST validate Content-Type: the RFC requires servers to fail the request if Content-Type is missing or inconsistent with the body — unlike the historically loose handling of GET bodies, which many servers/proxies strip or reject outright today.
• Responses are cacheable: a cache MAY reuse a stored QUERY response to satisfy a later identical QUERY request, something not safely possible with POST today.
• Adoption will be slow and uneven: tooling support is nascent (e.g., the Kreya API client added it in v1.20) and broad support across browsers, proxies, WAFs, and API gateways is expected to take years — mirroring how long PATCH took to become universally trusted after 2010.
• Primary target use cases: Elasticsearch/OpenSearch-style complex search bodies, GraphQL-shaped read queries, and any "search with 20 optional filters" endpoint currently forced onto POST /search purely to carry a body.

Relevance to My Work

Directly relevant to the Localz marketplace's API design. LocalzDocs/Marketplace-System-Design-Reference §7.2 ("Idempotency everywhere") already documents working around exactly this gap by hand: "HTTP POST endpoints accept Idempotency-Key" so retries don't cause double charges or duplicate notifications. QUERY targets the read-side counterpart of that same problem — once support matures, Localz's feed/search read models (§7.3, denormalized views serving filtered marketplace search) are a textbook candidate for QUERY instead of POST /search, getting safe-retry and cache semantics for free instead of needing a bespoke idempotency key on what's actually a read operation. Not something to adopt yet given the "years to full support" caveat, but worth flagging for the API layer once client/proxy support (Cloudflare, given viewer/ already runs on Cloudflare Pages) catches up.

Discussion

Q (2026-07-10): How mature is QUERY? Is it production-ready?

Short answer: the spec is done, the ecosystem isn't — treat it as "safe to prototype behind a feature-flagged fallback," not "safe to make the primary interface of a public API" yet.

• Spec status: RFC 10008 is a finished IETF Proposed Standard (June 2026), so the wire format and semantics aren't going to change. That part is stable.
• Servers/frameworks — early and uneven: nginx has an open, unmerged PR (nginx/nginx#1511, "Add basic RFC 10008 (QUERY method) support") as of late June 2026 — not in a shipped release. Symfony added support in 7.4, and API Platform can expose custom QUERY operations on top of that today via a manual operation definition (per api-platform/core discussion #7618); native framework-level support followed in a PR opened after the RFC published, i.e. weeks old. Generic servers that don't allowlist HTTP methods (many Node.js-based ones included) will pass a QUERY request through today basically by accident, since they never restricted the method string to begin with — that's not the same as "native support," just the absence of a blocker.
• Browsers/CORS: fetch/axios can send a QUERY request today since they don't restrict the method string either. But QUERY is not a CORS-safelisted method (only GET, HEAD, POST are), so any cross-origin use triggers a preflight OPTIONS, and the server must explicitly answer with Access-Control-Allow-Methods: ... QUERY. Same-origin use has no such friction.
• The original problem hasn't fully gone away: the RFC exists precisely because proxies, CDNs, WAFs, and API gateways historically strip or reject unrecognized bodies/methods. Until those — not just origin servers — widely recognize QUERY, anything sitting between the client and your server (corporate proxies, third-party WAFs, older load balancers) is a real risk of silently mangling the request.
• Practical recommendation: fine to adopt now for an internal or first-party API where you control the whole path (e.g., Cloudflare-fronted, given Cloudflare co-authored the RFC and viewer/ already runs on Cloudflare Pages) — with a QUERY → 405 → POST fallback. Not yet advisable as the sole interface for a public API consumed by unknown third-party clients/infra.
• Caveat on sources: several SEO-style "explainer" posts published right after the RFC (e.g. claiming Node.js "natively parsed QUERY since early 2024") contain claims that predate or contradict the RFC's own June 2026 publish date — likely low-effort rewrites rather than verified reporting. Treated those as unreliable and didn't carry them into the summary above; the framework-specific claims here trace to the nginx PR and the api-platform GitHub discussion directly.