HN Debrief

RFC 10008: The new HTTP Query Method

  • Infrastructure
  • APIs
  • Web
  • Standards
  • Developer Tools

RFC 10008 adds QUERY, a new HTTP method for requests that are safe and idempotent like GET but can carry a request body. The point is to support read-only operations that need more input than fits comfortably in a URL, without pretending they are POSTs. Typical examples are complex searches, GraphQL reads, and other large filter payloads. The RFC also keeps QUERY cacheable in principle and allows a server to answer with a `Location` for an equivalent GET-able result, so a large body-based query can be turned into a stable URL after the first request.

If you run APIs, treat QUERY as a semantic cleanup for existing `POST /search` style endpoints, not as a replacement for normal GETs. Watch browser, proxy, CDN, and framework support before betting product behavior on it, because middlebox support and caching behavior will decide whether this stays neat on paper or useful in production.

Discussion mood

Cautiously positive. People liked finally having a first-class HTTP method for body-carrying read requests, but a lot of the energy went into practical skepticism about proxy support, browser behavior, framework adoption, and whether body-aware caching is useful or just more moving parts.

Key insights

  1. 01

    Why QUERY beat GET-with-body

    Changing GET to have defined body semantics would collide with years of deployed behavior where intermediaries ignore, drop, or mishandle GET bodies. A new method is ugly, but it fails loudly with `405 Method Not Allowed` or similar instead of silently stripping the meaningful part of the request. That is the same pragmatic pattern behind newer status codes like `308 Permanent Redirect` instead of retrofitting older semantics.

    Do not read QUERY as protocol purism. Read it as a compatibility escape hatch. If you need body-based reads across unknown infrastructure, explicit failure is far safer than relying on undefined GET behavior.

      Attribution:
    • giobox #1
    • WorldMaker #1
    • advisedwang #1
    • greghines #1
  2. 02

    The main problem is URL size, not syntax

    The cleanest justification was not semantics alone. It was payload size. QUERY moves large read inputs out of the URL and into the body, which avoids the messy reality that URLs often fail somewhere around implementation-specific limits while request bodies are expected to be large. That makes QUERY a better fit for oversized searches and GraphQL reads than stuffing JSON or base64 into query strings.

    If your read endpoints already fit comfortably in URLs, keep using GET. QUERY earns its complexity when the input is large enough that URL limits, encoding hacks, or ugly client workarounds are becoming part of the design.

      Attribution:
    • cryptonym #1
    • Draiken #1
    • ralferoo #1
    • CodesInChaos #1
  3. 03

    Cacheability is optional and likely narrow

    People expecting a new universal HTTP cache primitive were overreading the RFC. Caches can hash the body as an opaque blob, refuse to cache large requests, or skip caching entirely and still be compliant. That means QUERY is cacheable in the same way many HTTP features are possible but not automatic. The body becoming part of request identity does not force smart normalization, and trying to canonicalize arbitrary payloads in generic infrastructure is exactly where bugs and security issues start.

    Assume QUERY gives you retry and semantics first, cache wins second. If caching matters, design it deliberately at the edge or application layer instead of assuming generic intermediaries will understand your query language.

      Attribution:
    • drdexebtjl #1
    • ralferoo #1
    • CodesInChaos #1
    • PunchyHamster #1
  4. 04

    The Location pattern is the practical bridge

    One of the most actionable patterns in the RFC is to accept a large QUERY once, then return a `Location` for a stable GET endpoint representing that result set or prepared query. That preserves clean semantics on the first request, then hands back a bookmarkable and CDN-friendly URL for reuse. Several people read this as the realistic way QUERY could fit existing caches and browser behavior instead of asking every cache to key directly on arbitrary request bodies.

    If you adopt QUERY early, pair it with a GET-able result URL. That gives clients and CDNs a conventional path while still letting you accept large safe request bodies up front.

      Attribution:
    • WorldMaker #1
    • ygouzerh #1
    • CodesInChaos #1
  5. 05

    HTML forms are where this gets tangible

    QUERY becomes much more compelling if browsers let forms submit with `method="query"`. That would remove the ugly refresh and resubmission behavior of safe operations currently tunneled through POST, and it would finally let user-facing web apps express read-only form submissions without abusing POST. The catch is that browser and HTML support does not come with the RFC, so this benefit is still hypothetical.

    Watch the WHATWG work, not just the RFC. If forms and fetch do not grow good QUERY support, adoption will stay concentrated in APIs and internal systems rather than mainstream web UX.

      Attribution:
    • CodesInChaos #1
    • acabal #1
    • amluto #1
    • sheept #1
  6. 06

    Safe matters more than idempotent

    Several comments sharpened a subtle but important point. QUERY is not just "POST but repeatable". It is defined as safe, which makes it a better semantic fit for reads than PUT and a better operational fit than POST for refreshes, retries, and tooling. That opens obvious use cases like GraphQL queries and streamed AI responses that are read-like in behavior but currently forced into POST because they need a body.

    When you model an endpoint, ask whether it merely tolerates retries or is actually read-only. QUERY is for the second case. Using it that way helps clients and infrastructure make better decisions automatically.

      Attribution:
    • cosmotic #1
    • inlined #1
    • CodesInChaos #1

Against the grain

  1. 01

    Adoption friction may outweigh the cleanup

    Even people who saw the design as correct doubted it would spread quickly. Existing systems already work with GET plus query strings for small inputs and POST for large ones, so QUERY asks every framework, proxy, gateway, and team to add plumbing for a problem many feel they already solved well enough. If support stays patchy, it risks becoming another technically right feature that is expensive to depend on.

    Do not force QUERY into public APIs just because the semantics are cleaner. Use it where you control both ends first, and wait for ecosystem support before making it part of a broad compatibility promise.

      Attribution:
    • TheGRS #1
    • barbazoo #1
    • lanycrost #1
  2. 02

    The protocol may be solving the wrong layer

    A minority view rejected the whole premise that HTTP needs another verb here. If you terminate TLS and control the stack, you can already implement safe body-based reads with POST and custom caching rules. From that angle, QUERY looks like standards work for a narrow infrastructure concern, while modern application protocols or controlled environments can solve it more directly without teaching the entire web another method.

    If all your traffic stays inside infrastructure you control, QUERY may offer little immediate payoff. Measure whether the real pain is semantics across third-party tooling or just a local convention you can already standardize internally.

      Attribution:
    • doctorpangloss #1
    • AtNightWeCode #1
    • wang_li #1
  3. 03

    The name QUERY will confuse people

    A few comments disliked the method name itself. "Query" is already overloaded through query strings, database language, and casual talk about requests, so the verb can sound like it only applies to searches even though the RFC makes it a general safe method with a body. That naming problem will make onboarding and docs slightly harder than the underlying idea deserves.

    If you expose QUERY in your API, explain it in terms of "safe request with a body" rather than assuming the verb name carries the semantics. Good documentation will have to compensate for the overloaded term.

      Attribution:
    • smashed #1
    • rehevkor5 #1

In plain english

`308 Permanent Redirect` ↩
An HTTP redirect status code that preserves the original request method and body when redirecting.
`405 Method Not Allowed` ↩
An HTTP response status code meaning the server understood the request method but does not allow it for that resource.
cacheable ↩
Able to have its response stored and reused by browsers, proxies, or CDNs for later equivalent requests.
CDN ↩
Content Delivery Network, infrastructure used to distribute web content and data efficiently.
GET ↩
An HTTP method used to retrieve data without changing server state, usually with parameters in the URL.
GraphQL ↩
A query language and API style where clients request exactly the data they want, often by sending structured queries in the request body.
HTTP ↩
Hypertext Transfer Protocol, the standard protocol browsers, APIs, and servers use to exchange web requests and responses.
idempotent ↩
A property where repeating the same request has the same intended effect as doing it once.
POST ↩
An HTTP method commonly used to submit data, often implying creation or other state-changing operations.
QUERY ↩
A newly standardized HTTP method for safe, idempotent requests that can include a request body.
RFC ↩
Request for Comments, the numbered documents used to publish Internet standards and related technical specifications.
safe ↩
In HTTP, a method that is intended only to read data and not cause significant state changes on the server.
SEARCH ↩
A WebDAV HTTP method defined earlier for search-like operations, mentioned as a precedent for QUERY.

Reference links

Standards and specifications

Browser and HTML support

IETF process and RFC numbering

Side references