HTTP QUERY Method: Search Filters Without Long URLs

Start with the request path, not a method replacement

QUERY is defined in RFC 10008, a June 2026 Standards Track document. It carries query input in the request body and explicitly gives the operation safe, idempotent semantics. That makes it worth evaluating for complex search filters—not an automatic replacement for a working GET or POST endpoint.

For a site owner, the first question is whether the deployed infrastructure can carry it. As checked on November 5, 2026, CloudFront's custom-origin documentation lists DELETE, GET, HEAD, OPTIONS, PATCH, POST and PUT as supported forwarding methods. QUERY is absent. Do not plan a CloudFront migration on the assumption that publishing the RFC enabled support.

Our recommendation: keep the existing search route while testing method forwarding, query interpretation and caching separately.

Where GET filters run into limits

RFC 10008 section 1 explains that URI-based queries become problematic when their input is too large, particularly across systems whose limits are not known in advance.

For illustration, the existing t-shirt search example puts filters into the URL:

GET /t-shirts?brand=nike,puma&size=m&color=black&max_price=30

This is an illustrative request, not a tested store endpoint or an example that exceeds a limit. The important deployment question is how large your actual requests become.

Amazon documents a maximum CloudFront URL length of 8,192 bytes. Its request-processing documentation says that exceeding the URL limit produces HTTP 414 (URI Too Long) and terminates the viewer connection. This is a CloudFront limit, not a universal HTTP maximum.

Moving those filters into a GET body is not a portable solution. RFC 10008's method summary identifies GET content as having no defined semantics. A concrete documented restriction is that CloudFront returns HTTP 403 for a viewer GET request with a body. Do not depend on GET-body filtering across an untested request path.

Keep POST semantics separate from CDN behavior

POST can carry a search body. The limitation is not that every POST search changes data: RFC 10008 section 1 explains that other components need specific knowledge of the resource and server to recognize a safe, idempotent query.

That distinction matters in three places:

• Application retries: an application that knows its POST search is read-only and idempotent can treat repeating it accordingly. Generic intermediaries cannot infer those properties from the POST method alone. Do not treat a search endpoint as equivalent to an order-creation endpoint merely because both use POST.
• HTTP caching: RFC 10008 Table 1 allows POST-response caching for subsequent GET or HEAD requests. This conditional reuse is not a general cache for repeated POST searches; “POST cannot be cached” is too broad.
• CloudFront behavior: AWS documents that CloudFront does not cache POST responses. A permitted POST search forwarded to the origin therefore cannot be answered from that CloudFront response cache. This does not rule out application-level caching.

Retries have a separate, documented CloudFront rule. Under Origin settings → Response timeout, AWS says CloudFront drops a timed-out POST connection without contacting the origin again. For GET and HEAD, it retries according to the configured connection-attempt count. This describes origin response timeouts—not every network failure, and not an application-level ban on retrying POST.

What a QUERY endpoint promises

The same illustrative filters could be sent as a QUERY body. This sketch is not a tested implementation; the endpoint would need to define and support this JSON query format. Transport framing is omitted.

QUERY /t-shirts HTTP/1.1
Host: shop.example
Content-Type: application/json

{"brand": ["nike", "puma"], "size": "m", "color": "black", "maxPrice": 30}

RFC 10008 section 2 defines the contract:

• Safe: the client does not request or expect a change to the target resource's state. This does not prohibit the server from creating additional resources for retrieving query information.
• Idempotent: the request can be repeated, including after a connection failure, without changing its intended effect through repetition.
• Content-aware: the request content and its media type define the query, within the scope determined by the target resource.

For caching, section 2.7 permits reuse of QUERY responses under HTTP caching rules and requires the cache key to incorporate request content and related metadata. It does not promise that a particular CDN implements that behavior.

For the illustrative store, a useful acceptance test is to send otherwise identical requests for black and white t-shirts and verify that cached responses are not mixed. Also test differing media types. These are proposed tests, not measured results.

A server can advertise its supported query formats through Accept-Query. It can also return a Location URL for repeating the query with GET, or a Content-Location URL for retrieving its results. Sections 2.3–2.4 distinguish those uses and note that the URLs may be temporary.

Validate the format before processing the filters

Require a Content-Type and reject missing or inconsistent media-type information. RFC 10008 section 2.1 distinguishes these cases:

Input problem	RFC guidance
Missing media-type information	Fail with a 4xx response, such as 400 Bad Request.
Declared media type inconsistent with the content	Reject the request; 400 Bad Request can be used. Do not infer a replacement media type by sniffing the body.
Media type unsupported by the target resource, including no defined QUERY semantics for that resource	415 Unsupported Media Type is appropriate. Accept-Query can identify supported formats.
Media type understood and content consistent with it, but the query's contents cannot be processed	422 Unprocessable Content can be used.

Do not collapse these into a blanket “return 415 or 422 for bad queries” rule.

Require evidence before changing the live search route

Use this deployment checklist as an acceptance plan, not as a claim that your stack already supports QUERY:

1. Trace the full path. Test the actual client, CDN, load balancer, proxy, WAF and application route. Record which component accepts or rejects the method.
2. Check interpretation. Confirm the endpoint recognizes the intended media type and applies every filter. Exercise the validation cases above.
3. Prove cache separation. Verify request content and related metadata are incorporated in the cache key as section 2.7 requires. Leave QUERY caching disabled until that behavior is demonstrated.
4. Test retry handling. Confirm repeated requests satisfy the endpoint's safe, idempotent contract. Record intermediary retry behavior separately from client behavior.
5. Retain the fallback. Keep the working GET or POST endpoint until all required clients and infrastructure pass. Advertise Accept-Query only for formats the endpoint supports.
6. Review deployment results. Compare returned filters, errors and origin traffic against your baseline before expanding use. No performance improvement is assumed here.

If your search is hitting URL limits, start with a request-path audit rather than a method-name change. Our website development and website speed optimization services can help plan that evaluation.