RFC 10008: The new HTTP Query Method

Original Article ↗ Hacker News Discussion ↗

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.