A new HTTP method (HTTP QUERY) has arrived, and it’s the most notable addition to the protocol in years. In this article, we’ll take a quick look at what HTTP QUERY is, why it matters, how F5 BIG-IP LTM and F5 BIG-IP Advanced WAF handle applications, and which APIs leverage the new method; from traffic delivery to security.
HTTP QUERY: the new HTTP method
If you’ve been keeping an eye on news lately, you may have noticed a new HTTP method, QUERY. This is one of the biggest additions to HTTP semantics in years, since PATCH. It was standardized by the IETF in RFC 10008, published in June 2026.
The HTTP QUERY method aims to solve a problem that has bothered web developers and API designers for years. The core issue is simple. When you need to send a request that contains a substantial amount of data to retrieve, there are two options:
- GET with a query string - safe, idempotent and cacheable, but you’re limited by URI length restrictions and most of the time, sensitive data in the URI ends up in logs, browser history, and proxy caches.
- POST with a body - allows you to send as much data as you want in the request body, but POST is not safe, idempotent by definition, which means intermediaries can’t cache the response and can’t safely retry the request.
The new QUERY method is the best of both worlds. It’s a safe, idempotent method that carries a request body. In other words, it behaves semantically like a GET (safe, idempotent and cacheable) but allows you to include a payload like a POST.
Here is an example of a common query pattern using GET:
GET /products?q=foobar&limit=10&sort=-published HTTP/1.1
Host: example.org
And the typical POST implementation:
POST /products HTTP/1.1
Host: example.org
Content-Type: application/x-www-form-urlencoded
q=foobar&limit=10&sort=-published
In this case, though, you can’t tell that the request is a safe, idempotent query without prior knowledge of the specific resource and server involved.
The QUERY method fills the gap between GET and POST, giving us the best of both. The example above can now be written as:
QUERY /products HTTP/1.1
Host: example.org
Content-Type: application/x-www-form-urlencoded
q=foobar&limit=10&sort=-published
To summarize:
| GET | POST | QUERY | |
|---|---|---|---|
| Safe | Yes | No | Yes |
| Idempotent | Yes | No | Yes |
| Cacheable | Yes | No | Yes |
| Content (body) | No defined semantics | Expected | Expected |
In HTTP terminology, a request method is considered safe when it is intended only for data retrieval and does not change the state of the server. As “safe” refers to intent, don’t assume the traffic does not need inspection or can’t carry a malicious payload.
BIG-IP LTM and the QUERY method
With the release of the new method, adoption will likely take some time as well as the support in many infrastructure components such as WAFs, API Gateways, Reverse Proxies, Load Balancers etc.
In general, BIG-IP LTM sits in front of a variety of webservers, frameworks and proxies and requires a more permissive HTTP profile. The HTTP profile accepts unknown methods by default. Depending on your security requirements, you can adjust your HTTP profile to allow only specific HTTP methods, including the brand-new one, QUERY.
It’s worth mentioning any iRules or Local Traffic Policies dealing with HTTP methods would need to be reviewed. Any logic that branches on HTTP::method is likely taking care of the classic methods (GET, POST, PUT, DELETE, etc.), hence an audit will ensure your iRules behave as expected once QUERY traffic starts flowing.
BIG-IP Advanced WAF and the QUERY method
BIG-IP Advanced WAF (formerly ASM) enforces HTTP method validation as one of its foundational checks. The security policy maintains an explicit list of allowed methods. Any method not on that list triggers the “Illegal method” violation. Out of the box, a security policy allows a defined set of methods such as GET, HEAD, and POST. Since QUERY is a brand-new method, it will not be in that list by default. The result: a QUERY request hitting a protected virtual server will trigger the Illegal method violation and the request will be blocked.
Allowing the QUERY method
Fortunately, BIG-IP Advanced WAF is flexible and powerful enough to meet customers’ requirements and to provide comprehensive security and protection. When your backend applications begin supporting QUERY, you’ll need to explicitly permit it in the security policy:
In the TMUI, browse to:
Security > Application Security > HTTP Message Protection > Headers > Methods > Add
Add QUERY to the list of allowed methods and apply/save the policy:
Figure 1: Adding QUERY method as an allowed HTTP method
Testing the configuration and traffic inspection
Before adjusting the WAF policy
Without the necessary adjustment, traffic is blocked when a client submits a QUERY request:
Figure 2: A QUERY request is blocked by the WAF policy due to the illegal method QUERY
After adjusting the WAF policy
Once the WAF policy is adjusted, a request with QUERY method is allowed and it reaches successfully the application:
Figure 3: A QUERY request goes through the WAF and the application replies to it properly
Malicious traffic inside the QUERY request gets blocked
The QUERY request might carry a malicious payload in a similar fashion of a POST request, and it is identified and blocked by the WAF accordingly:
Figure 4: A malicious QUERY request containing a command injection payload is blocked by the WAF
Figure 5: BIG-IP Advanced WAF log showing the blocked QUERY request
Additional considerations
According to the new RFC, a QUERY request from user agents implementing Cross-Origin Resource Sharing (CORS) will require a “preflight” request. Hence, CORS configuration might need to be adjusted. If you are handling CORS as part of BIG-IP Advanced WAF policy, you can specify the new method as part of the configuration. Here you can find a step-by-step on how to setup and adjust CORS on BIG-IP Advanced WAF.
Conclusion
The HTTP QUERY method is a welcome, sensible addition to the HTTP specification. It gives us an idempotent, cacheable method that can carry a body. As it moves through standardization and clients/servers begin adopting it, F5 administrators should be prepared to deal with it. QUERY is blocked by default as an Illegal Method in our WAF, as this is part of the secure baseline, hence, the policy needs to be adjusted to allow QUERY when your applications start supporting it. Keep in mind, malicious payloads travel in the QUERY body in the same way as POST. Unlike a simple allow-list, BIG-IP Advanced WAF inspects the request for any malicious activities, so regular security checks such as attack signatures for various web attacks (XSS, Command Injection, SQLi, SSRF, etc.), parameter inspection and content-profile enforcement will apply, providing advanced protection against malicious traffic.
Related content
Have you started seeing QUERY traffic in your environment? Please, share your experience in the comments section below.