RFC 10008: The New HTTP QUERY Method Explained

The IETF published RFC 10008 this month, formally standardizing a new HTTP method called QUERY. Think of it as GET with a request body - safe, idempotent, and cacheable, but without the URL length constraints.

Last updated: June 17, 2026

What QUERY actually is#

QUERY is a new HTTP method that allows clients to send query data in the request body instead of the URL. Like GET, it is defined as safe (no side effects) and idempotent (can be retried without issues). Unlike POST, it explicitly signals that the operation will not modify server state.

The RFC was authored by Julian Reschke (greenbytes GmbH), James M. Snell (Cloudflare), and Mike Bishop (Akamai), and was published as a Proposed Standard by the HTTP Working Group.

Here is the core comparison:

The problem it solves#

GET requests encode query parameters in the URL. URLs have practical length limits - around 2,000 characters is generally safe, though implementations vary. This works fine for simple queries but breaks down when you need to pass complex filter structures, large JSON payloads, or anything that does not fit in a reasonable URL.

The workaround has been using POST. But POST does not communicate that the operation is safe. Browsers show "are you sure you want to resubmit?" warnings. Caches cannot safely store responses. Automatic retry logic hesitates because POST might create duplicate resources.

GraphQL is a prominent example. GraphQL queries can be substantial - deep nested selections, multiple fragments, complex variables. Sending them as URL parameters hits limits quickly. So GraphQL uses POST, even though queries (as opposed to mutations) are inherently safe and idempotent.

QUERY solves this by providing a method that:

• Accepts a request body for complex query data
• Is explicitly safe and idempotent
• Can be cached
• Signals to intermediaries that retries are safe

What HN is saying#

The thread generated 105 comments with a mix of enthusiasm and pragmatic skepticism.

GraphQL came up immediately. Multiple commenters noted that QUERY is a natural fit for GraphQL queries. One wrote: "Using QUERY for GraphQL queries (not mutations) would be a good match. These only read data, but are sometimes bigger than the url length limit."

The name confused some people. The term "query" already appears in HTTP URLs (the query string portion). One commenter wrote: "Use the QUERY method in your http query to query search results. Do not add query parameters. I think the name is confusing."

Proxy and CDN support is the real question. A historically-informed commenter pointed out that WebDAV's SEARCH method had similar goals two decades ago and never gained traction because intermediaries stripped bodies from unfamiliar methods. "Until gateway and CDN support is real rather than just on paper, POST with a header marking the body as part of the cache key stays the pragmatic choice."

Some developers have been doing this anyway. One commenter admitted: "I've been sending request body along GET method for years now." The replies quickly noted why this is fragile - fetch() in browsers does not allow it, load balancers may strip the body, and caching behavior becomes unpredictable.

HTML forms sparked interest. Commenters discussed whether browsers would add <form method="query"> support. This would eliminate the "resubmit form?" warnings when refreshing search results. A WHATWG proposal for expanding form methods exists at github.com/whatwg/html/pull/11347.

The spec itself was praised. One commenter noted: "I don't think it's easy to write a spec that is complete and approachable like this. Really appreciate that."

Implementation details#

The RFC specifies several practical requirements:

Content-Type is mandatory. Servers must reject QUERY requests without consistent media type information, returning 400 (Bad Request) or 415 (Unsupported Media Type).

Caching uses the request body. Response caching incorporates both the request content and metadata. Caches may normalize insignificant differences to improve hit rates.

Multiple response patterns:

• Return results directly with a Content-Location header pointing to a URI for the cached results
• Return a Location header with a URI that reproduces the query via GET
• Return a 303 redirect to stored results

Security consideration: Moving query parameters from URLs to request bodies mitigates privacy risks from URL logging. However, servers should avoid putting sensitive query data into temporary URIs used in Location or Content-Location headers.

When to use QUERY#

Good fit:

• Complex search or filter operations with large parameter sets
• GraphQL queries (not mutations)
• Any operation that is logically safe and idempotent but exceeds URL length limits
• Scenarios where you want caching and automatic retries

Probably not:

• Simple queries that fit comfortably in URLs - GET still works fine
• Operations that modify server state - use POST, PUT, or DELETE
• Until your infrastructure (proxies, CDNs, load balancers) actually supports it

The adoption question#

The RFC is now published as a Proposed Standard, but adoption depends on implementation across the stack:

• HTTP libraries need to support the method
• Browsers need to handle it (fetch API, form submissions)
• Proxies and CDNs need to pass request bodies for unknown methods
• Frameworks need routing support

The WebDAV SEARCH method comparison from the HN thread is worth considering. Good ideas in HTTP specs sometimes take years to achieve widespread support, and sometimes never do.

For server-side applications where you control the full stack, you can start using QUERY today. For public APIs, the pragmatic move is probably waiting until major clients and intermediaries catch up.

---

FAQ#

What is RFC 10008?#

RFC 10008 is an IETF specification published in June 2026 that defines a new HTTP method called QUERY. It enables sending query data in the request body while maintaining safe and idempotent semantics like GET.

How is QUERY different from GET?#

GET encodes parameters in the URL; QUERY accepts them in the request body. Both are safe and idempotent. QUERY avoids URL length limits and keeps potentially sensitive query data out of logs.

How is QUERY different from POST?#

POST is neither safe nor idempotent - it may create resources or cause side effects. QUERY explicitly signals that the operation will not modify server state, enabling caching and automatic retries.

Can I use QUERY with fetch() in JavaScript?#

Browser support will need to be added. As of June 2026, mainstream browsers are evaluating implementation. Check your target browsers before depending on it for web applications.

Is QUERY good for GraphQL?#

Yes, QUERY is well-suited for GraphQL queries (as opposed to mutations). GraphQL queries are safe and idempotent but often exceed URL length limits when sent as GET parameters.

When will browsers support QUERY?#

RFC 10008 was just published. Browser implementation timelines vary. There is an active WHATWG proposal for HTML form method="query" support at github.com/whatwg/html/issues/12594.

---

Continue Reading#

• Cloudflare's Agentic Internet: Readable, Discoverable, Callable, and Payable
• Fable 5 Task Budgets: Capping Agent Spend Before It Happens
• Git Finally Gets a History Command Worth Using

Sources#

• RFC 10008: HTTP QUERY Method - IETF, June 2026
• Hacker News discussion - 105+ comments, accessed June 17, 2026
• WHATWG HTML form methods proposal - GitHub