HTTP gets a QUERY method so complex searches can stop pretending to be POST
Jump to main content
Search
REG AD
DevOps
HTTP gets a QUERY method so complex searches can stop pretending to be POST
New verb carries request content while remaining safe, idempotent, and cacheable
Joab Jackson
Joab<br>Jackson
SOFTWARE DEVELOPMENT AND CLOUD REPORTER
Published<br>mon 13 Jul 2026 // 12:15 UTC
"Idempotent" may be jargon, but the term performs an important job in HTTP as a hall pass that gives reverse proxies and gateways the go-ahead to cache complex query responses and automatically retry failed requests.<br>HTTP has long allowed automatic retries for idempotent methods, but complex queries are often sent using POST, which intermediaries cannot safely assume is retryable. Developers have worked around that limitation for decades.<br>The Internet Engineering Task Force (IETF) has published a new HTTP request method, QUERY (RFC 10008), joining familiar methods including GET, POST, PUT, and PATCH.
REG AD
In development since 2021, the QUERY request method provides a way for an HTTP client to make an idempotent request to an HTTP server. An idempotent request has the same intended effect whether it is sent once or multiple times (so retrying it should not charge a user's credit card again).
REG AD
The specification defines QUERY as safe and idempotent, and the solution was surprisingly simple.<br>"Thanks to QUERY, we finally have functional HTTP caching for complex requests. Proxies, CDNs, and browsers can now cache requests with a body. This is huge for performance," writes developer Elie Treport in a recent blog post.<br>Query operations have traditionally used the GET method. HTTP defines GET as safe and idempotent, as it made no changes to the server itself, but GET becomes awkward when the query data is too large or complex for a URI.<br>The idea behind GET was to load all the necessary query parameters onto the form's URL, resulting in a very long string that the browser sent to the server. Many search services still work this way, appending query parameters to the URL after a question mark. Those URLs can expose sensitive data through browser histories, server logs, and bookmarks.<br>Festooned with nested filters, sort rules, date ranges, and other database flotsam, GET URLs can become unwieldy. HTTP recommends support for URIs of at least 8,000 octets, but there is no universal maximum, so an oversized URL may be rejected by any of the systems it passes through.<br>Long query strings are also a pain to read and debug.<br>Faced with these Franken-URLs, many developers turned to POST instead. POST can carry query data in the request body, but its semantics do not tell intermediaries that the operation is safe and idempotent. The method is more commonly associated with operations such as submitting form data, uploading a PDF, or creating and modifying resources.<br>For a basic HTML form, switching to moves the encoded form data from the URL into the request body.
REG AD
Crafty developers soon began placing complex query payloads, often encoded as JSON, in POST request bodies and having their applications process the responses. Many APIs adopted the pattern; GraphQL, for example, commonly uses POST for queries, although it also supports GET.<br>It was a hack, though. This was not what POST was designed for. HTTP defines POST as neither safe nor idempotent by default. A POST request could change the server's state.
MORE CONTEXT
US state laws push age checks into the operating system
Speedier type checks in TypeScript 7.0 as first stable Go release ships
.NET's long-term support is not long-term enough, dev complains
AWS debuts Lambda MicroVMs with up to 8 hours runtime
And this is why internet networking software treats POST far more delicately than GET. Intermediaries generally cannot reuse POST responses for later POST requests or automatically retry POST without knowing the operation is idempotent. If the message fails, the browser or gateway will not resend it, necessitating intervention from either the user or the app.<br>QUERY's long road to adoption<br>So basically, QUERY combines request content similar to POST with explicitly safe and idempotent query semantics. No longer will the query URL need to be appended beyond recognition, but, like POST, apps and browsers will get a dedicated space to put their complex query data.<br>Unlike POST, QUERY is a read-only operation, and hence receives the IETF's blessing as idempotent, freeing up HTTP clients and intermediaries to cache and resend QUERY requests after a connection failure. A QUERY request does not ask or expect the server to change the state of the target resource. It's just there to ask a question.<br>Cloudflare and Akamai engineers co-wrote RFC 10008. Both companies provide edge caching for large clients. German internet engineering firm greenbytes also contributed.<br>As a new standard, QUERY still has limited support. The HTML forms standard still only understands GET and POST...