HTTP QUERY moves the search filter into the request body without giving up cacheability

InfoQ's account attaches one condition to the cacheability: responses stay cacheable as long as the cache key incorporates the request content ^[3]. That is a change to how a cache computes a key. Method plus URI no longer identifies a request, because two QUERY requests to /orders can differ only in their bodies. Anything on the path that wants to serve a stored response has to look at the body before it can look anything up.

The gap being closed sits at the middlebox. RFC 10008 notes that an intermediary seeing only POST /orders/search cannot know the operation was designed to be read-only, because that knowledge lives inside the application contract ^[6]. POST is neither safe nor idempotent, so caches skip it, clients cannot safely retry it, and intermediaries must assume it changes state ^[5]. QUERY carries a body like POST while keeping the safe, idempotent and cacheable semantics of a read ^[9]. The RFC also lists why the alternative gets ugly: URI length limits differ between components on the request path, some structures are awkward to encode, URIs land in logs and browser history, and every distinct parameter combination becomes a different URI ^[11].

The workarounds still matter today. GraphQL and Elasticsearch already tunnel complex reads through POST bodies ^[19]. One Hacker News commenter, quoted by InfoQ, described how Cloudflare caches those reads: "Their unofficial support for caching POST requests is to create a fake GET request to serve as cache key and use that to cache the response. This is the kind of hacks everyone is forced to go through instead of using something like QUERY" ^[21].

The obvious cheaper fix was a body on GET. In an r/webdev thread that drew more than 800 upvotes, one developer asked "Why not allow an optional request body in GET?" ^[13]. Another answered: "Failing silently is the most obvious to deal with a body on GET. Good luck debugging which server down the line dropped your body..." ^[14]. The same developer wrote that "By having a new method you ensure the party supports the body." ^[15].

Julian Reschke, James Snell and Mike Bishop wrote the specification after Asbjorn Ulsberg reopened the question at the 2019 HTTP Workshop ^[18]. That is roughly seven years from the corridor conversation to publication ^[20]. InfoQ says real adoption will likely be measured in years, as it was for PATCH ^[8], and the specification advises treating QUERY as additive, because a new method has to be understood by clients, servers, proxies and caches before it is dependable ^[7].

So QUERY beats POST /search on a given path only when the client library sends the method, the server framework routes it, and the caches in between key on the body. Servers can signal the middle part with the new Accept-Query field ^[4]. RFC 10008 keeps GET for small queries ^[10], which leaves a design review three options and a threshold someone has to pick.