RFC 10008: The new HTTP Query Method

Original Article ↗ Hacker News Discussion ↗

A new HTTP method called QUERY is being standardized to handle read-only requests with large, complex parameters in the request body, addressing longstanding URL length limits and the awkward use of POST for safe, idempotent operations like search or GraphQL queries. Proponents highlight benefits for caching, automatic retries, and clearer semantics, especially if browsers, CDNs, and HTML forms add support. Critics question whether introducing a new verb is worth the ecosystem-wide churn, arguing that standardizing GET bodies or adding headers to POST might have solved the same problems with fewer compatibility and implementation challenges.

Purpose and Semantics of QUERY

  • Introduces QUERY as “GET with a body”: read-only, safe, and idempotent.
  • Main goal: support complex/large queries (e.g., GraphQL, rich filters, images) without URL length limits.
  • Intended for data retrieval only; semantics similar to GET, but request parameters live in the body.

Caching, Idempotency, and Safety

  • Because QUERY is safe and idempotent, intermediaries and clients may cache and retry it automatically, unlike POST.
  • Debate over caching keys:
    • Concern: using the entire body as a cache key creates unbounded, user-controlled keys and complexity (ordering, normalization, hashing).
    • Counterpoints: this is optional; caches can hash the body, or better, servers can respond with a short Location URL that can then be cached via GET.
  • Side effects like logging and quotas are treated as “ignored” at the HTTP semantic level, same as for GET.

GET-with-body vs New Method

  • Some argue the spec should just standardize a GET body.
  • Others note many proxies/servers ignore, drop, or reject GET bodies, and it’s been long discouraged, so retrofitting semantics is unsafe.
  • New method avoids silent mangling: unsupported QUERY tends to fail clearly (e.g., 405) instead of discarding data.

Intermediaries and Compatibility

  • Concern: many middleboxes historically mishandle unknown methods or any method-with-body they don’t understand.
  • Without broad gateway/CDN support, POST plus custom headers remains the pragmatic choice for some.
  • QUERY must also deal with CORS: currently not safelisted, so browsers perform preflight, even though it is safe.

Use Cases and Developer Reactions

  • Suggested uses: large GraphQL queries, complex search filters, dry-run vs commit patterns (QUERY then POST), database-like queries, streaming AI queries with event streams.
  • Some see it as a clean semantic fix for “POST /search” hacks and better matches HTTP’s method model.
  • Skeptics see it as overkill: added complexity, new plumbing, and yet another nuance developers must learn, for a problem already “good enough” with GET/POST.

HTML Forms, Bookmarks, and UX

  • Interest in method="query" in HTML forms to avoid “resubmit POST data” warnings and better mapping to safe operations.
  • Broader desire to let forms use more HTTP verbs (PUT/DELETE/etc.) to align human interactions with REST semantics.
  • Concern about bookmarkability if query parameters live in the body; mitigations via server-generated GET URLs are discussed.

Naming and Conceptual Debates

  • Some find “QUERY” confusing given existing “query string” terminology.
  • A few argue HTTP verbs shouldn’t encode business semantics at all, viewing this as REST-driven overdesign; others counter that HTTP has always attached semantics to methods.