Three protocol engineers spent five years finishing a document that almost nobody outside the working group was tracking. Julian Reschke, James Snell of Cloudflare, and Mike Bishop of Akamai closed it in June, when the Internet Engineering Task Force published Request for Comments 10008, registering a new method for the Hypertext Transfer Protocol called QUERY. HTTP has not gained a new general purpose method since Request for Comments 5789 defined PATCH in 2010.

GET and POST Never Solved the Same Problem

GET is safe, cacheable, and idempotent, and it packs every parameter into the uniform resource locator. That works until a search filter grows past what a browser, a proxy, or a gateway will accept in a request line, and different intermediaries enforce different limits with no way to know which one applies until a request fails. POST accepts a body of any size and structure, but nothing in the protocol tells an intermediary that the request only reads data. Caches skip it by default. Retries carry risk of duplicate writes that were never intended.

A retail site filtering by size, color, and price range fits inside a GET request without trouble. Add fifteen filters, a date range, and a sort order, and the request line grows past what some proxies and gateways accept, with no reliable way to know the limit until the request fails. A finance dashboard filtering three years of transactions by region, category, and amount, then grouping and sorting the result, hits the same wall and gets pushed onto POST instead, where it loses caching and the safety to retry without side effects.

QUERY takes the cacheable, safe semantics of GET and pairs them with a structured request body. The same faceted product search, the same dashboard filter, or an agent issuing a complex retrieval call can now send a real payload and still be cached, retried, and treated as read only by every compliant intermediary on the path.

The Authors Are the Story

Two of the three RFC 10008 authors work for companies that sit in front of a meaningful share of the web's traffic, and that fact shapes the rollout. Cloudflare and Akamai operate the content delivery networks, edge caches, and web application firewalls that will decide how fast QUERY becomes usable, faster than any browser vendor decides to ship it. Support so far reflects that split. Node.js has parsed the method natively since 2024. The OpenAPI 3.2 specification documents it. .NET 10 shipped client and server support at launch. Spring had not shipped support as of July 2026, and no major browser implements QUERY natively yet. The Web Hypertext Application Technology Working Group is still working through how HTML forms would submit one.

That leaves a gap most coverage of the RFC treats as a footnote. Standardization solved the protocol problem. It did not touch the reverse proxies, load balancers, gateways, and firewalls that enterprises already run in front of production traffic.

Method allowlists written before June 2026 have no reason to know QUERY exists, and a rule written to recognize four methods does not automatically recognize a fifth.

Security Teams Have a Review Item Before Product Teams Have a Feature

QUERY did not inherit Cross-Origin Resource Sharing safelist status from GET, so browser JavaScript sending it triggers a preflight request. Web application firewalls, API gateways, and reverse proxies configured against a fixed list of methods, typically GET, POST, PUT, DELETE, and PATCH, may reject QUERY outright or route it through rules built for something else entirely (Hive Security, 2026). Caches present a sharper risk. QUERY is explicitly cacheable, and the specification requires the cache key to include the request body along with the path. A cache that hashes or normalizes that body incorrectly opens the door to cache poisoning or cache deception, and that is a configuration detail, not a protocol flaw.

None of this requires an enterprise to have adopted QUERY yet.

It requires a security team to confirm what its own perimeter does when a client, a partner integration, or an agentic system sends a method the firewall was never told to expect.

Even Google's Own Search Team Is Explaining This in August

Gary Illyes, an analyst on Google's search relations team, posted an explainer on LinkedIn this month walking developers through the same GET versus POST tradeoff RFC 10008 already resolved, and estimated that widespread adoption, including support in Google Search itself, is a matter of years rather than months. That timeline is not a knock on Google. It is a useful data point on how long a finished protocol standard takes to move through browsers, crawlers, content delivery networks, and every framework an enterprise has already deployed. The specification cleared its last procedural hurdle in June. The parts of the internet that have to recognize QUERY in practice are still working through it two months later, and Google's own search infrastructure is one more example, not an outlier.

A Finished Standard Still Has Four Layers to Cross

Ratification is the easy part. No single company controls the rest of the path, so each layer adopts on its own schedule. Server frameworks move first, since that layer is cheapest to change. Node.js parsed QUERY natively before the RFC was even finalized, and .NET 10 shipped support at launch. Infrastructure comes next, the reverse proxies, gateways, and content delivery networks that sit between users and servers. Given that two of the three authors work at Cloudflare and Akamai, that layer has a head start most new HTTP methods don't get. Browsers are typically last, partly because HTML's own form standard has to be updated first, a separate effort the Web Hypertext Application Technology Working Group is still finishing. Only once those three layers are in place does it become safe for an ordinary enterprise to assume traffic using QUERY will behave correctly end to end.

HTTP QUERY sits between the first and second layer today. That is exactly why a security review outranks a product roadmap item right now.

What Happens Next

Three questions determine how fast this moves from protocol footnote to production concern. Will Cloudflare and Akamai ship edge level QUERY support before major frameworks catch up, given that both companies co-authored the specification. Will the Web Hypertext Application Technology Working Group finish HTML form support before or after browsers ship the method natively. And will enterprise security teams treat the current gap as a proactive audit item, or wait for the first cache poisoning incident tied to a misconfigured QUERY cache key to force the question.