www.it-connect.fr
HTTP QUERY: The First New HTTP Method Since 2010
In June 2026, the IETF published RFC 10008 and formalized the QUERY method, designed to fill a gap in the HTTP protocol: sending a large request body like with POST, while keeping the guarantees of GET. Here’s what you need to know about this new method.
GET or POST: QUERY bridges the gap
To query a service, developers have traditionally had to choose between two methods, each with its own drawback.
GETis safe, idempotent, and cacheable, but parameters travel in the URL. The problem is that URL length is not guaranteed end to end (the RFC notes that the recommendation is to support at least 8000 bytes). Encoding a complex filter in a query string quickly becomes unreadable, and URLs end up in logs, browser history, and bookmarks.
GET /feed?q=foo&limit=10&sort=-published HTTP/1.1
Host: example.orgPOSTaccepts a large request body, but nothing in the protocol indicates that the operation is safe and read-only. As a result, caches cannot use it, and automatic retries after a network interruption become risky.
POST /feed HTTP/1.1
Host: example.org
Content-Type: application/x-www-form-urlencoded
q=foo&limit=10&sort=-publishedIdempotent, safe... Two terms that deserve a quick explanation, because everything depends on them.
- Safe: the request does not ask for any modification of the resource. It reads it, it does not change anything. The server is of course allowed to do work behind the scenes (logging, hitting a database, writing a temporary result), but the visible state of the targeted resource remains unchanged.
- Idempotent: sending the request once or ten times in a row produces the same effect on the server. This is the guarantee that allows a client, proxy, or CDN to automatically replay a request after a network interruption without wondering whether it just created ten orders instead of one.
GET is therefore used to retrieve a resource (an image, a CSS stylesheet, etc.), especially when loading a web page. Meanwhile, countless search APIs use POST for simple lookups, losing HTTP caching and safe retries in the process. That is where QUERY comes in.
The method carries the request content in the message body, like POST, but it is explicitly safe and idempotent, like GET. The RFC summary table captures the logic: where POST is potentially unsafe and non-idempotent, QUERY checks both boxes, which re-enables caching and automatic replay in case of problems. The method has also been registered by IANA in the official HTTP methods registry.
In practice, how does an HTTP QUERY request work?
A server that receives a QUERY request processes the content and returns the result in a 200 OK. The RFC adds two mechanisms. First, a new response header, Accept-Query, which makes it possible to indicate what is accepted for the QUERY request, especially which formats (the RFC cites media types such as application/sql, application/jsonpath, or application/xslt+xml). Then, the server can return a Location header pointing to an equivalent resource accessible through a simple GET, so that a request can be bookmarked, shared, or replayed without resending the body every time.
Here is what a QUERY request looks like:
QUERY /feed HTTP/1.1
Host: example.org
Content-Type: application/x-www-form-urlencoded
q=foo&limit=10&sort=-publishedFor those who want to review the basics before going further, our dedicated article on how the HTTP protocol works revisits methods, status codes, and protocol versions.
Security and caching: what QUERY changes
Beyond developer convenience, QUERY has direct operational and security implications in both directions.
On the benefits side, three points stand out.
- Caching becomes possible again for complex searches. Because it is safe and idempotent, a
QUERYresponse can be cached by a CDN or reverse proxy, somethingPOSTdid not allow. The RFC does note, however, that the cache key must include the request body, which makes the operation more expensive than a simpleGETcache. - Replays become safe. In case of a connection drop, a client or intermediary can resend the request without fear of side effects, since the method is idempotent by definition.
- Privacy improves. Filters travel in the body rather than in the URL. The RFC points out in its security considerations that URLs are more likely to be logged than a request body, making
QUERYa relevant choice when the request contains sensitive data.
On the caution side, this new feature requires review work that security teams would be wrong to overlook.
QUERYis not a CORS "safelisted" method. A cross-origin request will therefore trigger a preflight, as stated clearly in the RFC security considerations (which refer to the Fetch specification).- Your web application firewalls (WAFs) and API gateways are probably configured to ignore the QUERY method (because it is not in the list of allowed methods). A filter that is too strict will reject it, while one that is too permissive could let it bypass a rule designed for
POST. Some configuration tuning will certainly be required.
As with every protocol change, adoption remains the big question. This is not an RFC draft; it is official, but it still has to be implemented. The presence of Cloudflare and Akamai among the authors of this new feature suggests that support will arrive quickly on the CDN side. Elsewhere, the path will likely be longer, including in web browsers.
The standard is published, but your software stack will not understand it overnight: QUERY will not replace either GET or POST anytime soon, as millions of applications still rely on the existing methods.
To learn more, here are some useful links:
