The new HTTP QUERY method explained

Original Article ↗ Hacker News Discussion ↗

A newly standardized HTTP method, QUERY, aims to provide a safe, idempotent, cacheable way to send complex request bodies for reads—something developers have long worked around by misusing GET with bodies or POST for queries. Commenters weigh whether adding a new verb is better than formally allowing bodies on GET, highlighting issues with existing proxies, CDNs, WAFs, and browsers that strip or mishandle GET bodies and the challenges of caching based on request payloads. Many see clear use cases for search, GraphQL, and large or sensitive filters, but expect slow, uneven adoption across the existing HTTP infrastructure.

What QUERY Is Meant to Solve

  • Seen as “GET with a body” formalized: safe, idempotent, cacheable, but can carry a request body.
  • Intended to replace hacks like GET-with-body or POST-for-queries (e.g., search, GraphQL queries).
  • Advocates say it clarifies semantics for intermediaries: “this can be cached, is read-only, and has a body.”

Why Not Just Fix GET?

  • One camp: simply standardize GET-with-body; QUERY is redundant “XKCD standards” bloat.
  • Counterpoint: many existing proxies, WAFs, CDNs, and frameworks strip or reject GET bodies or treat them as meaningless.
  • Changing GET semantics would create undefined behavior in legacy systems; a new method can cleanly fail with 405 and allow fallback to POST.
  • Some argue both paths require updating infrastructure anyway; they see QUERY as marketing rather than technical necessity.

Compatibility, Middleboxes, and Browsers

  • Concerns that badly maintained “black box” middlewares may mishandle new verbs or crash.
  • Others say standards must evolve despite legacy gear; broken infra should be fixed.
  • Several note browsers are unlikely (or at least not guaranteed) to implement QUERY soon; that limits web-facing adoption.
  • Accept-Query header and OPTIONS/405 are cited as mechanisms to negotiate support.

Proposed Use Cases

  • Search APIs like Elastic/OpenSearch currently abusing GET-with-body or POST; QUERY would be a natural fit.
  • GraphQL: use QUERY for read-only queries, POST for mutations.
  • Complex filtering/search in web apps: JSON bodies instead of long query strings.
  • Reverse image search and other file- or binary-based queries.

Caching, Semantics, and REST

  • QUERY is defined as cacheable and idempotent; this opens CDN/proxy caching unlike POST.
  • Skeptics note practical cache keys: bodies lack a standard canonical form (JSON ordering, whitespace), complicating shared caches.
  • Some argue QUERY improves REST/CRUD clarity by separating simple GET-by-URL from more complex queries; others say you can model queries as resources (POST to create, then GET).

Security, WAFs, and Practical Pain Points

  • Many note real-world systems that reject or strip GET bodies (WAFs, CloudFront, strict API gateways).
  • QUERY is seen as a way to avoid these undefined behaviors and security rules that treat GET-with-body as suspicious.
  • Others warn QUERY itself won’t be supported by such systems initially, so migration remains non-trivial.