Every web developer knows the core HTTP methods by heart: GET, POST, PUT, DELETE, and PATCH. For sixteen years, that list did not change. In June 2026, it finally did. The Internet Engineering Task Force published RFC 10008, standardizing a new HTTP method called QUERY, the first addition to this list since PATCH arrived in 2010.
It sounds like a small technical footnote, but QUERY quietly fixes a problem that almost every API developer has run into and worked around in slightly different, slightly awkward ways for years. Understanding what it does, and why it took this long to arrive, says a lot about how the web actually works under the hood.
The Problem QUERY Was Built to Solve
At the heart of HTTP is a simple idea: every request should say what kind of action it is performing. GET means read something. POST means submit or create something. PUT means replace something. DELETE means remove something. This is what makes caching, security tools, and browsers behave predictably across the entire internet.
The trouble starts when you need to read data using a complex, structured query, the kind with nested filters, multiple sort conditions, or long lists of IDs, and that query is too large or too complex to fit cleanly into a URL. Developers have had exactly two imperfect options for years.
Option one: GET with a query string
This is semantically correct. GET is safe, idempotent, and cacheable, which means it will not change anything on the server, repeating it is harmless, and browsers and CDNs can store the response and reuse it. The problem is size. URLs have practical length limits enforced inconsistently by browsers, proxies, and servers. A search with a dozen filters, nested conditions, and sort rules quickly turns into an unreadable, fragile string of characters.
Option two: POST pretending to be a read
To get around the size limit, many teams simply used POST instead, sending the filter criteria in the request body. This works in practice, but it breaks the meaning of the protocol. Nothing about a POST request tells a browser, a cache, or a security tool that this particular request is actually just a safe, read-only lookup. That misclassification quietly costs teams caching benefits, and it can confuse tools that rely on HTTP methods to understand what a request is supposed to do.
QUERY was designed specifically to close this gap. It behaves like a hybrid of the two: it carries a request body the way POST does, but it is explicitly safe, idempotent, and cacheable the way GET is. A client can send a large, structured filter object in the body of a QUERY request and both ends of the connection know, by definition, that it is a read-only operation that can be cached and safely repeated.
What Makes QUERY Different, Technically
The RFC defines a few properties that set QUERY apart from the methods developers already know:
- Safe: sending a QUERY request does not change anything on the server. It is purely a read operation, by definition.
- Idempotent: sending the same QUERY request multiple times produces the same result, so it can be retried automatically after a network failure without any risk of side effects.
- Cacheable: responses to QUERY requests can be cached the same way GET responses are, but the cache key must account for the request body, not just the URL.
- Has a body by design: unlike GET, QUERY was built from day one to carry structured content such as JSON, so complex filters no longer need to be squeezed into a URL.
- Its own distinct semantic: intermediaries such as proxies, gateways, and firewalls can now tell the difference between a state-changing POST and a genuinely read-only QUERY, instead of guessing.
A simple example makes the shift clear. Instead of sending a search as a plain GET request with a long, awkward query string, or disguising it as a POST, a client can now send a QUERY request with a clean JSON body describing exactly what it wants to search for, sort by, and filter on, while both the client and server understand that this is a safe, cacheable, repeatable read.
Why It Took So Long
The idea behind QUERY is not new. Developers have wanted a safe method with a body for years, and early work on this exact proposal, often discussed under the name "Safe Method with Body," has been active in the IETF's HTTP working group since around 2021. Standardizing any part of HTTP is a slow, deliberate process precisely because so much of the internet's infrastructure, browsers, proxies, firewalls, content delivery networks, and server frameworks, has to eventually agree on how to handle it.
That same caution now shapes the rollout. QUERY is officially a standard, but the surrounding ecosystem is still catching up. Some web application firewalls, older reverse proxies, and load balancers were configured with rules written specifically around GET, POST, PUT, DELETE, and PATCH. A method they do not recognize may simply be rejected or handled unpredictably until those systems are updated. Browsers also need updates of their own; the HTML forms standard, for instance, still only understands GET and POST for ordinary form submissions, so native browser support will take additional work.
The Impact on Technology
Even in its early days, QUERY is likely to reshape a few specific corners of how APIs and web infrastructure are built.
Cleaner, more expressive APIs
Search endpoints, analytics dashboards, and filter-heavy applications are the most obvious beneficiaries. Instead of cramming complex filter logic into an ugly query string or misusing POST, API designers finally have a method that says exactly what is happening: a big, structured, read-only request. It is the kind of clarity that pays off in any API-first architecture.
A new job for caches and CDNs
Because QUERY responses are cacheable but the cache key must include the request body, caching systems need real updates to handle this correctly. Get it wrong, and there is a genuine risk of cache poisoning or cache deception, where a cache accidentally serves one user's query result to another user with a different query. This is one of the more delicate parts of adopting QUERY safely, and it is drawing serious attention from the security community already.
Security tooling needs a refresh
Web application firewalls, CORS policies, and CSRF protections are all typically written with specific HTTP methods in mind. QUERY is not automatically treated as a browser safelisted method, so browser based JavaScript needs a CORS preflight check before using it. Security teams now have a very concrete task: review whether their existing rule sets, gateways, and middleware treat QUERY deliberately, rather than letting it slip through unexamined simply because it is unfamiliar.
A slow, uneven rollout
Support is arriving quickly in some places. Some modern web frameworks and recent versions of major reverse proxies and cloud load balancers are already adding support or passing QUERY through untouched. But broad, dependable support across the entire chain, browsers, CDNs, corporate proxies, and older enterprise software, is expected to take through 2027 and into 2028 before it becomes safe to assume everywhere.
The Impact on Business
For business leaders and product teams, a new HTTP method might sound like the kind of detail that only engineers need to care about. In practice, it has a few concrete implications worth knowing.
Better performance for data heavy products
Any product built around search, filtering, or complex data lookups, e-commerce catalogs, analytics dashboards, recruiting platforms, real estate portals, could eventually see faster response times and lower infrastructure costs once QUERY support matures, because previously uncacheable POST-based searches can become properly cacheable.
A near-term security review, not a rewrite
Businesses running their own APIs, firewalls, or API gateways should treat this as a prompt for a security and infrastructure review rather than an urgent rewrite. The practical question is simple: do your existing security tools and caching layers already have rules written for GET, POST, PUT, DELETE, and PATCH that quietly ignore or mishandle anything else? If so, QUERY is a good reason to check that now rather than after it becomes common in the wild.
A competitive edge for early, careful adopters
Companies that build genuinely complex search or filtering products, and get comfortable using QUERY correctly and securely ahead of their competitors, stand to gain a real, if modest, edge: cleaner APIs, better caching economics, and infrastructure that is easier to reason about. This is particularly relevant for SaaS platforms and API-first businesses, where request efficiency and caching directly affect hosting costs.
Vendor and platform dependency
Most businesses will experience this change indirectly, through the cloud platforms, CDNs, and software vendors they already use, rather than by implementing QUERY themselves. It is worth asking key vendors, cloud providers, API gateway vendors, e-commerce platforms, whether and when they plan to support QUERY, particularly if search or filtering performance is central to the product.
No reason to rush, but good reason to plan
Because full ecosystem support will likely take a year or two to mature, there is no pressure to adopt QUERY immediately. The sensible approach for most businesses is to note it as an item on the technology roadmap, ask vendors about their support timelines, and revisit it seriously once frameworks, browsers, and security tools have caught up.
Frequently Asked Questions
What is the HTTP QUERY method?
The HTTP QUERY method is a new, officially standardized HTTP request method defined in RFC 10008. It lets a client send a large, structured, read-only request with a body, similar to POST, while remaining safe, idempotent, and cacheable, similar to GET.
When was the HTTP QUERY method standardized?
The IETF published RFC 10008 in June 2026. It is the first new standard HTTP method since PATCH was standardized in 2010.
Is QUERY the same as POST?
No. QUERY carries a request body like POST does, but unlike POST, it is explicitly safe and read-only. Servers, browsers, and caches can treat it as a lookup that never changes data, which POST cannot guarantee.
Does QUERY replace GET?
Not entirely. GET remains the right choice for simple reads. QUERY is meant for complex, structured reads where the filter criteria are too large or too complex to fit cleanly into a URL.
Is the HTTP QUERY method widely supported yet?
Support is still catching up. Some frameworks, proxies, and cloud load balancers are adding QUERY support already, but broad support across browsers, CDNs, and older enterprise infrastructure is expected to take through 2027 and 2028.
Should my business adopt QUERY right away?
There is no need to rush. Most businesses will get QUERY support indirectly through their cloud providers and software vendors. It is a good idea to ask key vendors about their QUERY support timeline and keep it on the technology roadmap.
Where This Leaves Us
QUERY is a quiet but genuinely useful addition to the web's foundation. It does not change what the internet can do, but it makes a common, everyday pattern, sending a complex read request, finally behave the way developers always wanted it to: safely, predictably, and efficiently. Like most infrastructure level changes, its real impact will show up gradually, in slightly faster search results, slightly lower hosting bills, and slightly cleaner code, long after most people have stopped thinking about the method name behind the request.
This piece reflects the HTTP QUERY method as standardized in RFC 10008, published by the IETF in June 2026. Ecosystem support across browsers, proxies, and frameworks is expected to continue evolving through 2027 and 2028.
