HTTP QUERY: The Method That Finally Closes the Gap Between GET and POST

The HTTP method that was missing between GET and POST: safe, idempotent, cacheable, with a request body. From proposal to IETF standardization.

Anyone who has built a search API knows this dilemma. You want to expose an endpoint for complex queries: multiple filters, sorting, a GraphQL expression, maybe a SQL-like query. The first idea is to use GET, which is the semantically correct method: it’s safe, idempotent, cacheable. But GET has no defined body, so all that complexity has to end up in the URI as a query string. That works as long as the parameters are few. Then length limits show up (different and unpredictable depending on client, proxy, and CDN), encoding nested structures becomes unreadable, and sensitive data ends up logged and bookmarkable in plain sight in the URL.

So most developers give up and use POST. It works: the body can hold any structure. But POST is neither safe nor idempotent: an intermediary can’t assume that repeating the request is harmless, so no automatic caching, no safe retries, no CDN optimizations. That’s exactly the choice GraphQL, gRPC-over-HTTP, SOAP, and XML-RPC have made for years: use POST even for read-only operations, paying the price in caching and semantics.

For years this was an accepted compromise. On June 19, 2026 it stopped being one: the IETF published RFC 10008, “The HTTP QUERY Method,” as a Proposed Standard. Let’s look at where this proposal comes from, how it works in detail, and what it means for API designers today.

The new HTTP QUERY method opens a path between the two trails worn so far, GET and POST.

Where the proposal comes from

The idea of a safe HTTP method with a request body isn’t new: WebDAV already did it in 2003 with SEARCH (RFC 5323), and even earlier with PROPFIND and REPORT. The problem with those methods is that they carry all the semantic baggage of WebDAV, designed for a very specific namespace (resource and property management), and they don’t generalize well to the rest of the web.

The proposal for a generic method, explicitly designed to close the gap between GET and POST across all of HTTP, has circulated in the HTTP Working Group community for several years: the first public discussions date back to at least 2021, when the initial draft (which later became draft-ietf-httpbis-safe-method-w-body) started circulating among developers. From there it went through numerous revisions, fourteen draft versions, discussions on the HTTPbis Working Group mailing list, and several rounds of Last Call, until it reached official publication as an RFC in June 2026.

The authors, three names with no small weight in the HTTP ecosystem, are Julian Reschke (greenbytes, historically a co-editor of the HTTP/1.1 specifications), James M. Snell (Cloudflare), and Mike Bishop (Akamai). The document was sponsored by the IETF’s HTTPbis working group, with Gorry Fairhurst as the responsible Area Director.

A detail the authors explicitly clarify in the document: the chosen name is “QUERY,” not one of the existing WebDAV methods (SEARCH, REPORT, PROPFIND), precisely to avoid the semantic ambiguity of those methods and better capture the conceptual link with a URI’s query component, generalizing the pattern to any type of resource, not just WebDAV.

The problem it actually solves

The central point, which RFC 10008 spells out in its introduction, is that neither classic method covers the case of complex read-only queries well.

The limits of GET:

• URI length limits aren’t clear or uniform: they vary from client to client, proxy to proxy, CDN to CDN, and exceeding them produces errors that are hard to diagnose;
• some data structures are awkward or impossible to correctly encode in a URI (deep nesting, binary data, long free text);
• request URIs are more likely to end up logged, saved in browser history, or bookmarked, exposing data that maybe shouldn’t appear in plain text in a log.

The limits of POST:

• it’s neither safe nor idempotent, so a client or intermediary can’t automatically retry the request after a network error without risking side effects;
• it isn’t cacheable by default, which complicates the job for CDNs and reverse proxies in front of APIs that, in fact, always return read-only data;
• semantically it’s ambiguous: a client can’t infer from the method alone whether a POST creates, updates, deletes, or simply reads something.

QUERY takes the body from POST and the safety/idempotence from GET, while also staying cacheable: the combination GraphQL and friends have, in effect, been trying to simulate for years by using POST as a workaround.

How it works in practice

A QUERY request looks like a POST, but with the explicit guarantee that the server won’t change the state of the target resource. The Content-Type is mandatory, because it defines the format in which the query is expressed: it can be JSON, an application-specific format like application/graphql, a structured query format like application/jsonpath, or even plain text.

An example with a GraphQL query:

QUERY /api/graphql HTTP/1.1
Content-Type: application/graphql

{ users(role: "admin") { id name email } }

An example with a structured JSON search filter:

QUERY /feed HTTP/1.1
Content-Type: application/json

{
   "q": "distributed systems",
   "limit": 10,
   "sort": "-published",
   "filters": ["status:active", "type:post"]
}

And an example closer to a SQL-style query, with a CSV response:

QUERY /contacts HTTP/1.1
Host: example.org
Content-Type: example/query
Accept: text/csv

select surname, givenname, email limit 10

If the server doesn’t understand or doesn’t accept the Content-Type sent, it responds with precise error codes: 400 Bad Request if the header is missing or inconsistent, 415 Unsupported Media Type if the format isn’t supported, 422 Unprocessable Content if the syntax is valid but the query can’t be processed, 406 Not Acceptable if it can’t produce a response in the format requested by the client’s Accept.

The Accept-Query header

RFC 10008 also introduces a new response header, Accept-Query, with which a resource declares both support for the QUERY method and the query formats it accepts, using Structured Field Values syntax (RFC 9651):

HTTP/1.1 200 OK
Allow: GET, QUERY
Accept-Query: application/json, application/graphql

Caching, conditions, and redirects

This is where much of the method’s practical value lies. The cache key of a QUERY response includes, besides the target URI, the request content and relevant metadata: two different queries on the same endpoint produce distinct cache entries, but identical queries can be served from cache without hitting the backend.

QUERY also supports conditional requests, exactly like GET: a client can send If-None-Match with an ETag and receive 304 Not Modified if the result hasn’t changed, or use If-Modified-Since, If-Match, If-Unmodified-Since, and even range requests.

To link the response to a concrete, reusable resource, the server has three options:

1. include a Content-Location header pointing to a resource downloadable with a subsequent GET;
2. include a Location header for repeatable queries in the future;
3. respond with a 303 See Other redirect to a URI reachable via GET.

And here’s an interesting difference from classic redirect behavior: QUERY preserves its own method across 301, 302, 307, and 308 redirects (a client following those redirects repeats a QUERY, it doesn’t turn it into GET). Only 303 explicitly converts the subsequent request into GET, which is exactly the mechanism designed to “materialize” a query’s result as a standalone resource.

One detail worth keeping in mind for anyone working with public APIs exposed to the browser: QUERY is not CORS-safelisted, so cross-origin requests require an OPTIONS preflight, exactly as already happens today for many POST requests with a non-simple Content-Type.

Where adoption stands

Publishing an RFC as a Proposed Standard doesn’t mean the whole ecosystem supports it the next day. It’s the first rung of the IETF standards track: the specification is stable and ready for implementation, but it takes time for browsers, servers, proxies, CDNs, and client libraries to actually adopt it.

Currently, no major browser implements QUERY natively. On the server side things move faster: Node.js added support for the method in its http module already during the draft phase, and Go, thanks to how net/http is designed, effectively supports any custom method (including QUERY) via http.NewRequest, with no changes needed to the standard library. Right after the RFC’s publication, framework communities like Ruby on Rails opened public discussions to evaluate native support.

A case relevant for readers of this blog: DMVCFramework, the reference REST/MVC framework for Delphi, already has a study underway to evaluate and design support for the QUERY method. If you want to follow these technical decisions closely, discuss them, or propose concrete use cases, the right place is the DMVCFramework Patreon: that’s where I share this work in preview before it goes public.

The pattern one would expect is the same seen with other HTTP methods and headers that became standard over the last twenty years: first server-side adoption and dev tools, then consolidation in frameworks, and finally, more slowly, native browser support and JavaScript APIs like fetch(). In the meantime, anyone who wants to experiment can already do so server-side: at the transport protocol level, HTTP has never prevented custom methods, so implementing an endpoint that responds to QUERY today is already possible with most server-side stacks, as long as you account for clients, intermediate proxies, and CDNs that may not yet know the method and could behave unpredictably.

What this means for API designers

For anyone working today on REST APIs or GraphQL-style endpoints, QUERY isn’t urgent, but it’s a method worth keeping a close eye on, because it solves a real, widespread problem without introducing a new format or protocol, just a missing piece of HTTP. Some practical considerations:

• It’s not (yet) time to replace production traffic. With zero browsers supporting it natively, any real use today goes through custom HTTP clients or server-to-server libraries, not a form or a fetch() in a generic browser.
• It’s a natural candidate for internal or server-to-server endpoints. If you control both the client and the server, for example in a microservices architecture, you can already get correct semantics and caching on complex queries today without waiting for browser support.
• It simplifies the design of search and GraphQL-style APIs. Instead of forcing POST for read-only operations, QUERY finally offers a semantically correct way to express “I’m reading, with a complex query, and this request is safe to retry and cache.”
• You don’t need to reinvent anything on the infrastructure side. Being simply a new HTTP method, all existing infrastructure based on standard headers (cache, ETag, redirects, content negotiation) keeps working, as long as the various intermediaries along the path recognize it correctly.
• The conversation between a Delphi client and a DMVCFramework server. A very concrete case for anyone working with Delphi: a desktop application (VCL or FMX), a Windows service, or another server, written in Delphi or in any other language, that needs to query a DMVCFramework backend with articulated search filters (multiple fields, date ranges, sorting, pagination). Today the choice is between a GET with a query string that’s awkward to build and potentially too long, or a POST that gives up caching and idempotence just to “fit” the filter into the body. With QUERY, that client can send the filter as a structured body (typically JSON) to the DMVCFramework endpoint, getting correct semantics, safe retries in case of a network error, and the real possibility of leveraging cache and reverse proxies in front of the server, something not possible with POST today.

Key takeaways

• The gap between GET and POST now has a name. QUERY combines the body of POST with the safety and idempotence of GET, while also staying cacheable.
• It’s real, not just a proposal anymore. RFC 10008, “The HTTP QUERY Method,” was published by the IETF as a Proposed Standard on June 19, 2026.
• It doesn’t come out of nowhere. It’s conceptually inspired by WebDAV’s SEARCH (RFC 5323, 2003) but generalizes the pattern to the whole web with a new name and no WebDAV baggage.
• It has precise syntax. Mandatory Content-Type, new Accept-Query header to declare supported formats, dedicated error codes (400, 415, 422, 406).
• It preserves HTTP’s caching and safety guarantees. Cache key based on content and URI, conditional requests, redirects that preserve the method (except 303).
• Adoption is still early. No native browser support yet, but Node.js and Go already support it server-side, and frameworks like Ruby on Rails and DMVCFramework (for Delphi) are evaluating adoption.

Frequently asked questions

What is the HTTP QUERY method?

QUERY is a new HTTP method, standardized as RFC 10008, that lets you send a request with a body (like POST) while keeping safe and idempotent semantics (like GET). The server processes the request content and responds with the result, without changing the state of the target resource.

How is it different from GET and POST?

GET is safe and idempotent but has no defined body, so complex queries end up in the URI with awkward length limits and encoding. POST accepts a body but is neither safe nor idempotent, so it isn’t cacheable and can’t be safely retried automatically. QUERY takes the body from POST and the safety/idempotence from GET, while also staying cacheable.

Has the QUERY method been officially accepted?

Yes. On June 19, 2026, the IETF published RFC 10008, “The HTTP QUERY Method,” as a Proposed Standard, the first rung of the IETF standards track. The authors are Julian Reschke, James M. Snell, and Mike Bishop, produced by the HTTPbis working group. The method is now registered in the IANA HTTP Method Registry as safe and idempotent.

Do browsers and frameworks already support QUERY?

Support is still early. No major browser implements it natively at the time the RFC was published. Node.js added server-side support in its http module, Go already supports it like any custom method via http.NewRequest, and communities like Ruby on Rails opened discussions to add it right after the RFC was published. Progressive adoption is expected over the coming months and years, not immediately.

Why not reuse WebDAV methods like SEARCH, REPORT, or PROPFIND?

Because they carry the semantic baggage of WebDAV (RFC 5323, RFC 3253, RFC 4918), designed for a very specific namespace, and don’t capture well the conceptual link with a URI’s query component. The authors of RFC 10008 chose a new name, QUERY, precisely to avoid that ambiguity and generalize the pattern to the whole web.

Will DMVCFramework support the QUERY method?

A study is already underway to evaluate and design support for the QUERY method in DMVCFramework, the REST/MVC framework for Delphi. Anyone who wants to follow this work closely, discuss it, or propose use cases can join the DMVCFramework Patreon.

Sources and further reading: IETF, RFC 10008, “The HTTP QUERY Method” (June 2026); IETF Datatracker, document tracking page; http.dev/query; kmcd.dev, “The HTTP Query Method”; Anton Oko, “HTTP QUERY: A New Method For Search Queries” on Medium; Dan Horovits, “HTTP’s New Method for Data APIs: HTTP QUERY” on Medium; discussion on Hacker News.