The easiest way to think about QUERY is that it combines the best parts of GET and POST. Like GET, it is safe and idempotent, meaning the request is read-only and can be retried without causing side effects. Like POST, it allows a request body, so clients can send large or complex query payloads such as JSON filters, GraphQL queries, or SQL-like search expressions. For years, developers either crammed huge filters into URLs or used POST for read-only searches even though POST technically implies a state-changing operation. QUERY finally gives APIs a protocol-level way to say, “this is a read-only query, but it needs a body.” The IETF specification also makes QUERY responses cacheable, which is one of the reasons API vendors are interested in it.
From an F5 perspective, the important question is whether your BIG-IP devices recognize and process QUERY correctly. According to F5 DevCentral, modern BIG-IP LTM and Advanced WAF versions can identify the QUERY method, but existing security policies may not automatically allow it. Many organizations use positive security models that explicitly permit only methods such as GET and POST. In that environment, QUERY requests may be blocked until the policy is updated. F5 administrators should review LTM iRules, HTTP profiles, ASM/AWAF method enforcement settings, API gateway policies, and any upstream proxies or CDN configurations that validate HTTP methods. A forgotten allowlist entry can easily turn into a mysterious “405 Method Not Allowed” problem during an application rollout.
The security angle is where this gets really interesting. QUERY moves query parameters from the URL into the request body, which can reduce exposure in browser history, reverse-proxy logs, and analytics tools. However, that does not make the data invisible. WAFs, API gateways, and logging systems still need to inspect the body for injection attacks, malformed JSON, oversized payloads, and other abuse patterns. F5 notes that Advanced WAF inspection policies should be updated so QUERY traffic receives the same level of scrutiny as POST requests. Another subtle point is that QUERY is not a CORS-safelisted method, so browsers will perform a preflight request before sending it across origins. That means API teams may need to update CORS configurations in addition to WAF rules.
My take is that QUERY is less of a revolution and more of a long-overdue cleanup of HTTP semantics. Most existing applications will continue using GET and POST for quite a while, but new API frameworks are already experimenting with QUERY support. If you manage F5 infrastructure, this is a good opportunity to audit method enforcement policies before developers start using it in production. Add QUERY to your allowed-method lists where appropriate, verify that WAF signatures inspect the body, test caching behavior, and monitor logs for unexpected method usage. The protocol finally has a clean way to express complex read-only searches; now the operational challenge is making sure the network and security stack understands that new language.
References
1. F5 DevCentral — New HTTP QUERY method: What F5 Admins Need to Know
2. IETF RFC 10008 — The HTTP QUERY Method
https://datatracker.ietf.org/doc/rfc10008/
3. F5 DevCentral — A Method for the Madness: Meet HTTP QUERY
https://community.f5.com/kb/communityarticles/a-method-for-the-madness-meet-http-query/347063
4. F5 DevCentral — Limit HTTP Methods to ONLY GET and POST (method enforcement examples)
5. Vensas — The New HTTP QUERY Method – and How to Use It Today
https://vensas.de/en/blog/http-query-method-dotnet-10
