Just another unique way to voice out.: RFC 10008: HTTP Finally Has a Method Built for Real Queries

The IETF has been quietly working on a new HTTP method for most of the last decade. RFC 10008, The HTTP QUERY Method, was published in June 2026 — and within hours it had reached the front page of Hacker News at #2. The headline is small. The fix is not. HTTP, the protocol that has carried the web since 1991, has finally been given a method that does what most working developers have been using POST for all along: send a query in the request body without lying about what the operation is. The spec is short, precise prose for a fix that, in retrospect, should have shipped years ago.

The setup: the problem with POST-as-query

For most of the public web's history, the canonical "send a query to a server" pattern has been a GET request with the query string in the URI: GET /feed?q=foo&limit=10&sort=-published. This works fine until the query input gets large, sensitive, structured, or all three. RFC 10008's introduction lists four reasons GET-with-URI-query becomes "problematic" once the input outgrows the URI:

URI size limits aren't predictable across proxies, CDNs, and origin servers. RFC 9110 §4.1 recommends 8,000 octets but doesn't require it.
Encoding complex data (JSON, GraphQL, SQL) into a valid URI costs overhead and loses structure.
URIs get logged everywhere — access logs, browser history, Referer headers, bookmarks. Sensitive inputs end up in places they shouldn't.
Every distinct input combination becomes a distinct resource by URL. That makes caching, rate-limiting, and analytics all harder than they should be.

The pragmatic workaround most APIs adopted in the 2010s was to use POST for queries — POST a form body, get a result back. Stripe's POST /v1/charges/search, Algolia's POST /1/indexes/*/queries, GitHub's POST /search/code, every internal /api/search endpoint you've ever built: all POST. The problem is that POST is not safe. RFC 9110 §9.2.1 defines safe methods as those "intended to be read-only." By the spec, sending POST across the wire is asking the server to mutate state — even when the developer and the documentation both agree it isn't. The mismatch between intent and method is the bug. Caches don't cache POST the way they cache GET. CDNs don't replay it the way they replay GET. And the Allow: header, the audit log, the OPTIONS preflight, the rate-limiter's heuristics — none of them have an honest signal to work with.

What RFC 10008 actually defines

The RFC is short, careful, and unusually well-written for an IETF standards-track document. The full text is at datatracker.ietf.org/doc/html/rfc10008; the abstract page is at rfc-editor.org/info/rfc10008/. Three authors: Julian Reschke (greenbytes), James M. Snell (Cloudflare), Mike Bishop (Akamai). Document type: RFC, Proposed Standard. Working group: httpbis.

The mechanism is one new method called QUERY. The canonical example, lifted verbatim from §1 of the spec:

QUERY /feed HTTP/1.1
Host: example.org
Content-Type: application/x-www-form-urlencoded

q=foo&limit=10&sort=-published

That looks almost identical to the POST example. The differences are all in what the method promises:

Property	GET	QUERY	POST
Safe	yes	yes	potentially no
Idempotent	yes	yes	potentially no
URI for query itself	yes	optional (`Location`)	no
URI for query result	optional (`Content-Location`)	optional (`Content-Location`)	optional (`Content-Location`)
Cacheable	yes	yes	yes, only for future GET/HEAD
Request content	"no defined semantics"	expected	expected

The table is the whole story. QUERY takes everything useful from POST (request body with structured content) and everything useful from GET (safety, idempotency, cacheability, replayability) and gives you a method that actually matches what you've been doing.

The spec also defines one new response header: Accept-Query. Servers return it to advertise which query media types they accept on a given resource. The RFC example is Accept-Query: "application/jsonpath", application/sql;charset="UTF-8". This is the counterpart to Accept: for the request side. JSONPath (RFC 9535, Feb 2024), XSLT, and SQL are all given as worked examples in Appendix A.6 — the spec is opinionated about what a "query format" should look like and points at existing standards rather than inventing a new one.

What QUERY fixes in practice

Three concrete things change once an API can advertise QUERY support:

Caches can finally cache query responses honestly. RFC 10008 §2.7 makes caching legal and well-defined: "The response to a QUERY method is cacheable; a cache MAY use it to satisfy subsequent QUERY requests." The cache key has to incorporate the request content and metadata, not just the URL. That means Varnish, Fastly, Cloudflare, and browser HTTP cache can all hold onto a query result and serve a repeat request without a round trip to the origin — exactly the property POST deliberately does not have. If the server returns a Location: header pointing at an "equivalent resource" URI, the client can switch to plain GET for subsequent traffic and skip the body entirely. This is the architectural payoff.

Cross-origin requests become preflighted honestly. RFC 10008 §4 spells out the security considerations: "A QUERY request from user agents implementing Cross-Origin Resource Sharing (CORS) will require a 'preflight' request, as QUERY does not belong to the set of CORS-safelisted methods." This is the right answer. A POST-as-query from the browser is currently lying to the CORS layer about what it's doing. A QUERY is honest. The preflight cost is a real cost, but it's the cost of doing the right thing on the wire.

The audit log is finally correct. When your reverse proxy, WAF, or API gateway sees a QUERY request, it knows — at the protocol layer, not because of a URL convention — that the operation is read-only and safe to retry. The Allow: header now means something. OPTIONS preflights get a real answer. Logging systems that classify by method get a true positive instead of a false negative.

Why this took 31 years

Appendix B of the RFC, titled "Selection of the Method Name 'QUERY'," is unusually candid about the history. The IANA HTTP Method Registry already contains three other methods that are safe and idempotent: PROPFIND (RFC 4918, 2007), REPORT (RFC 3253, 2002), and SEARCH (RFC 5323, 2008). All three originated in the WebDAV activity. The early drafts of RFC 10008 — it went through 14 versions under the working name draft-ietf-httpbis-safe-method-w-body — used the name SEARCH. The working group eventually picked QUERY for three reasons spelled out in the spec:

The existing methods use a generic XML media type and define their semantics inside the request content. QUERY deliberately does not — it lets the resource pick its own media type and the Accept-Query header advertises support.
The existing methods all originate in WebDAV, which the spec notes "many" in the broader HTTP community have mixed feelings about.
The name QUERY "captures the relation with the URI's query component well" — i.e., it tells you what the method is for without requiring you to know it's the renamed SEARCH.

The fact that the IETF went through 15 drafts over what is conceptually a one-paragraph change tells you something. HTTP is the most-deployed protocol in human history, and changing it costs more than changing anything else on the internet. The fix is small. The review process that produced the fix was enormous.

What RFC 10008 does not do

A short honesty list:

It does not replace GET. GET with a URI query string is still the default for short, cacheable, loggable queries. The RFC is explicit about this — GET is the "common query pattern" and QUERY is the alternative when GET becomes problematic. Roughly: if your query fits in a URL and doesn't carry anything sensitive, GET is still right.

It does not replace POST for non-queries. If the operation mutates state — creates a record, sends an email, triggers a workflow — POST stays POST. QUERY is not a license to relabel every POST in your codebase. Relabeling a state-mutating POST as QUERY is a spec violation; the server is allowed to return 4xx, and clients are allowed to retry it indefinitely. The retries will hit your rate limiter and your audit log and your database in ways you do not want.

It does not specify what the query means. QUERY is media-type-driven. application/sql means SQL. application/jsonpath means JSONPath. application/xslt+xml means XSLT. The RFC does not invent a new query language; it standardizes the carrier. Which media types are interesting is up to the application, and the spec uses XSLT and SQL and JSONPath as examples because those are the formats that already have the necessary shape.

It does not immediately make your API support QUERY. Every origin server, every client library, every CDN, every WAF has to be updated before QUERY becomes useful in production. As of the RFC publication, none of the major servers have shipped QUERY support. Browsers will need CORS-safelist updates. The spec is the legal foundation; the ecosystem rollout is a multi-year project.

The original take: this RFC is small because HTTP is conservative on purpose

The thing the spec gets right that nobody is making explicit: it does almost nothing. There is one new method, one new response header, and one optional request pattern. The IETF spent 14 drafts and roughly a decade of working-group time to ship something that fits in 31 pages and changes three lines of HTTP semantics. That restraint is the story.

HTTP is the protocol that runs the web. Every change to it is paid for by every cache, proxy, CDN, library, browser, and developer who implements it. The cost of a bad change is enormous. The cost of a slow, conservative, one-method-at-a-time process is that the protocol moves slowly. Both costs are real. The fact that QUERY has been "almost done" for a decade is not a failure of the IETF — it is the IETF working as designed. The alternative — a faster process that ships more methods and more headers with less review — is the kind of process that produces security holes and ecosystem fragmentation. The web cannot afford that.

The interesting secondary observation is who shipped this. The author list is greenbytes (a small consultancy run by Julian Reschke, the same person who edited RFC 9110, the core HTTP semantics spec), Cloudflare (Snell), and Akamai (Bishop). This is the CDN layer of the web shipping a spec that makes caching of query responses a first-class operation. That is not a coincidence. The CDN operators are the ones who pay the cost of POST-pretending-to-be-GET in cache misses, in WAF CPU cycles, in origin shield traffic. The QUERY method is, among other things, an admission from the edge operators that the workaround the application layer adopted in 2010 is expensive at the network layer, and the right fix is at the protocol layer.

What this means for you

If you ship a public REST API with any POST /search or POST /query endpoints — read RFC 10008 §1 and §2 carefully. The honest answer for many of these endpoints is "switch the method to QUERY and add an Accept-Query: response header." You don't have to wait for server support; you can ship QUERY today with any framework that lets you register custom HTTP methods. Clients that don't understand QUERY will return 501, which is the correct behavior for an unknown method.
If you maintain an HTTP client library, server framework, CDN, or WAF — the work is just starting. Method registration in your parser, CORS-safelist policy, cache key derivation that includes the body, audit log categorization by method: all four pieces need a code change. The RFC's Appendix A.4 and A.5 are the test vectors; the Appendix A.6 examples are the integration tests.
If you design APIs — the design question changes from "GET-with-query-string or POST-with-body" to "GET-with-query-string, QUERY-with-body, or POST." The QUERY option is now on the table for any read operation whose input doesn't fit in a URL.
If you write about web infrastructure — the talking point is not "HTTP has a new method." The talking point is that the most-deployed protocol in human history just shipped a fix for a 30-year-old workaround, and the fix is small on purpose. The protocol layer's conservatism is the feature.

What to do this week

    ## Step 1. Read the spec. The text version isn't on rfc-editor.org yet
    #    (as of 2026-06-17, the /rfc/rfc10008.txt URL returns 404); use
    #    datatracker.ietf.org/doc/html/rfc10008 for the canonical HTML.
    #    The IANA HTTP Method Registry entry for QUERY is the canonical
    #    confirmation that the method is registered.

    ## Step 2. Audit your codebase. Grep for POST endpoints whose intent
    #    is read-only (search, filter, query, lookup, list-by-criteria,
    #    export-where-clause, etc.). The honest classification for these
    #    is QUERY, not POST. The audit output is your migration list.

    ## Step 3. Ship a proof-of-concept. Pick one internal read-only
    #    endpoint, add the method to your server's allowed methods list,
    #    return Accept-Query on OPTIONS, and point a curl at it. The
    #    query below is a simplified JSONPath example shaped like the
    #    real RFC 10008 Appendix A.6 example (which queries RFC errata
    #    by status and submit date); substitute your own path and
    #    filter for the one your team is migrating:
    #
    #      curl -X QUERY 'https://internal.example/api/orders/search' \
    #           -H 'Content-Type: application/jsonpath' \
    #           -d '$..[?@.status=="open"]'
    #
    #    Confirm: 200 OK with the JSONPath result, a Content-Location
    #    header if the resource is cacheable, and a 405 Method Not
    #    Allowed from any path that hasn't been updated.

    ## Step 4. File an issue. If you maintain a framework, server, CDN,
    #    WAF, or client library: file the QUERY method support issue now,
    #    while the spec is fresh. Reference draft-ietf-httpbis-safe-method-w-body-14
    #    if your issue tracker is RFC-version-strict; RFC 10008 if it's
    #    not. The work is months, not weeks.

    ## Step 5. Wait for the ecosystem. Don't ship QUERY to production
    #    for public-facing APIs until at least one major CDN and one major
    #    browser implement CORS preflight and cache-key support. The spec
    #    is the legal foundation; the ecosystem is the deployment surface.

Disclosure

This post was researched with AI assistance: the RFC text was fetched with curl --compressed from datatracker.ietf.org/doc/html/rfc10008 and rfc-editor.org/info/rfc10008/; the trend signal was sourced from the Hacker News front page; cross-references (RFC 9110, RFC 9111, RFC 9535, RFC 4918, RFC 3253, RFC 5323) were confirmed against the IETF datatracker. The synthesis, original-take section, and recommendations are the author's. No quotes in the body are fabricated; the example HTTP exchanges in the body and the Appendix A.6 examples are taken from RFC 10008 directly. The note that rfc-editor.org/rfc/rfc10008.txt returns 404 (and that the canonical HTML is on datatracker) was verified live at the time of writing.

Sources

RFC 10008, The HTTP QUERY Method — Reschke, Snell, Bishop. June 2026. https://datatracker.ietf.org/doc/html/rfc10008
RFC 10008 abstract / info page — https://www.rfc-editor.org/info/rfc10008/
IANA HTTP Method Registry (where QUERY is registered) — http://www.iana.org/assignments/http-methods
RFC 9110, HTTP Semantics — Fielding, Nottingham, Reschke. June 2022. https://www.rfc-editor.org/info/rfc9110 (the core spec QUERY builds on; defines safe and idempotent)
RFC 9535, JSONPath: Query Expressions for JSON — Gössner, Normington, Bormann. February 2024. https://www.rfc-editor.org/info/rfc9535 (the JSONPath query example in RFC 10008 §A.6 references this)
Hacker News discussion: "RFC 10008: The new HTTP Query Method" — submitted by schappim, 17 June 2026. https://news.ycombinator.com/item?id=48568502 (82 points, 43 comments at time of writing; numbers moving as the thread ages)

Just another unique way to voice out.

Wednesday, June 17, 2026

RFC 10008: HTTP Finally Has a Method Built for Real Queries