What does the HTTP specification say about sending a request body with a GET, and what should you do instead when query criteria are too large for a URL?

## What the spec actually says HTTP's message grammar allows content on any request, so a GET with a body is syntactically well-formed. But RFC 9110 states that **content received in a GET request has no generally defined semantics**, that it cannot alter the meaning or target of the request, and that sending it may cause some existing implementations to reject the request. Clients **SHOULD NOT** generate content in a GET unless they know the server supports it. So it is neither forbidden nor meaningful. "Undefined" is the worst category to build on: nothing is required to work, and nothing is required to fail loudly either. ## Why it breaks in practice 1. **Intermediaries.** Reverse proxies, CDNs, WAFs and load balancers vary: some forward the body, some strip it, some reject the request outright. Code that works against your local server can fail after deployment behind a CDN, or fail only for requests that happen to route through one edge. 2. **Servers and frameworks.** Some parse it happily, some ignore it, some return 400. Behaviour has also changed across versions of popular servers. 3. **Clients.** Several HTTP client libraries refuse to attach a body to GET or need special flags; a few silently convert the request to POST. Command-line and browser tooling is similarly uneven — `fetch()` in browsers throws if you give a GET a body. 4. **Caching is body-blind — the fatal one.** An HTTP cache's key is the method plus the effective request URI, refined by `Vary` on *headers*. There is no mechanism to include the body. Two GETs with identical URLs and different bodies are the *same* cache entry, so a shared cache can serve the results of one query to another user's query. That is a correctness and potentially a data-leak bug. 5. **Retries and redirects.** Automatic retries and redirect handling may not replay the body, producing requests with different meaning on retry. ## The legitimate motivation The reason people want it is genuine: a search with many structured filters does not fit comfortably in a query string. URI length has no fixed limit in the specification, but implementations impose their own — browsers, proxies and servers commonly cap somewhere in the low thousands of characters, and servers enforce configurable request-line limits. Deeply nested criteria also encode badly into flat key/value pairs, forcing invented syntaxes. ## The four practical options **1. POST with a body.** `POST /orders/search` with a JSON criteria document. Simple and universally supported. Costs: the request is no longer safe or idempotent by declaration (even though it only reads), responses are effectively uncacheable, and semantically you have labelled a read as a processing action. Most teams take this deal. **2. POST-then-GET (a search resource).** POST the criteria, get back **201** (or 200) with the identifier or `Location` of a stored query, then `GET /searches/{id}/results?page=2`. Now the results have a URI: cacheable, bookmarkable, shareable, paginable. Costs: an extra round trip and server-side state with a lifetime policy. This is the pattern worth naming for large, reusable or expensive queries. **3. Keep it in the URI.** Shorten parameter names, use a compact encoding, or compress and base64url the criteria into one parameter. Retains full cacheability but hurts readability and still has a ceiling. **4. The QUERY method.** The HTTP community standardised a **QUERY** method precisely for this: a method that is **safe and idempotent like GET but carries a request body**, with responses that can be cached against a key derived from the body. It is the correct long-term answer; adoption across intermediaries and frameworks is the gating factor, so treat it as the direction of travel rather than something to deploy blindly today. ## What to say if a system already does it Some widely used systems do accept GET-with-body (several search engines historically did, on their own controlled clients and network paths). That is fine when you own both ends and every hop in between. The moment a public client, a third-party proxy, or a CDN enters the path, the guarantee disappears. If you must support it, also accept POST for the same operation so clients have a fallback, and never rely on shared caching for those responses. ## The interview-worthy summary Name the spec position (undefined semantics, SHOULD NOT generate), then the *mechanical* reason it cannot be rescued by convention — caches key on URI and headers, not the body — and finish with the tradeoff ladder: POST for simplicity, POST-then-GET when cacheable results matter, QUERY as the standardised fix.