Browsers and APIs can struggle when query data outgrows a URL’s safe length or when you want a clear signal that a request is both safe and repeatable. RFC 10008 adds a new HTTP method, QUERY, that treats heavy or structured query input as message content rather than stuffing it into the URI. Unlike POST, which can have side effects and isn’t obviously idempotent, QUERY is explicitly safe (no state changes) and idempotent (repeatable without harm). That makes caching, retries, load balancers and other intermediaries handle these requests predictably. A QUERY request looks just like POST except for its method name. You send “QUERY /feed HTTP/1.1” with a Content-Type header (for example, application/x-www-form-urlencoded or JSON) and the query parameters in the body. Servers can return a Content-Location or Location header to give you a stable URI for that specific query or its result. You might see a 303 See Other pointing to a GETable URL, or a 200 OK with both result content and a Content-Location for later reference. This specification also defines an Accept-Query header so clients can ask for supported query formats, much like Accept for media types. It spells out how caching should work: intermediaries treat QUERY responses like GET responses when they carry explicit freshness metadata. Conditional requests, range requests and redirections follow patterns already defined for GET and POST but with the safety guarantees of QUERY in place. Finally, the document covers IANA registrations for the new method name and the Accept-Query header field, and it walks through examples—from basic form-encoded queries to JSON payloads, conditional retrieval via ETags, and indirect responses where an initial QUERY points you to a separate resource for the actual data. Security considerations highlight that, despite its read-only intent, servers must still guard against injection attacks and ensure proper validation of incoming query content.