Summary

  • RFC 10008 gives HTTP a safe, idempotent QUERY method whose request content and media type define the query. The registration creates an implementation obligation; it does not prove that a particular handler is free of business side effects.
  • QUERY content belongs in the cache key. Redirects, validators, Accept-Query, and optional equivalent-resource URIs distribute authority among client, cache and origin. A cleaner URI does not make the content private.

Imagine a client submitting a structured search over thousands of records. The expression is too elaborate to be a comfortable URI. GET is attractive because retrieval is safe and repeatable, yet RFC 9110 assigns no generally defined semantics to content received with GET. POST readily carries a body, but it is potentially unsafe and non-idempotent. When the connection dies after the upload, the client cannot infer from the method alone whether repeating it is an ordinary retry or a duplicate business action.

RFC 10008, published in June 2026 as a Proposed Standard, creates QUERY for this gap. A QUERY asks the target resource to process a query represented by request content. The content is required; its media type says what kind of query it is; content and relevant metadata together define the request. IANA now records QUERY as safe and idempotent and records Accept-Query as a permanent HTTP field.

This is not “GET with a body.” It is a separate method with its own contract. Nor is it POST with better branding. Safety means the intended semantics are read-only. Idempotency means multiple identical requests have the same intended effect as one, even if responses differ because time, representation selection or server state changes. Both properties are promises an implementation must keep. Neither is a certificate attached to arbitrary application code.

The registry allocates reliance

Method properties matter because other actors rely on them. A crawler, browser, SDK or recovery loop may automate a safe method more readily than an unsafe one. A transport implementation may retry an idempotent request after a failure whose execution point is uncertain. A cache can store a response only under method-specific rules it understands.

That reliance creates a sharper operational test than “the endpoint only reads today.” Does evaluation trigger billing, consume a one-time token, move a queue cursor, approve an action, rotate a credential, reserve capacity or emit an externally consequential audit event? Incidental logging is compatible with safety; a requested business mutation is not. A handler can be deterministic and still unsafe. Conversely, an idempotent operation need not return identical bytes on every invocation.

Running code must therefore carry the claim. A route declaration, API description or registry line proves what the system promises, not what the origin did. A useful trace connects method, exact content fingerprint, media type, authentication context, execution record, side effects and returned representation. When a retry occurs after a broken connection, the trace must show whether the first execution reached the application and whether the second changed anything it was not permitted to change.

The body is not cargo outside identity

The most consequential cache rule in RFC 10008 is easy to miss: a cache key for QUERY has to include the request content and relevant content metadata. Two requests to the same URI with different query bodies are not the same request. A cache indexed only by method and URI can serve the result of one search for another.

This means a cache may have to consume the complete content before deriving its key. A streaming path that previously forwarded bytes as they arrived may acquire buffering, memory and latency consequences. Maximum body sizes and back-pressure are therefore part of deployment design, not mere implementation detail.

Normalization adds another authority. A cache that understands a query media type may recognize semantically insignificant differences: perhaps object member order or an agreed whitespace form does not alter the expression. Correct normalization can improve reuse. False-positive normalization makes two distinct questions share one answer. Lexical resemblance is not evidence of semantic equality, and Cache-Control: no-transform is an instruction within HTTP's transformation model, not an audit proof that no component canonicalized the key.

The safe default is byte- and metadata-aware separation until the media type supplies a canonicalization rule that every relevant parser shares. Test both directions: different encodings of one meaning, and deceptively similar encodings of different meanings. Include duplicate fields, number formats, Unicode normalization, default values, order-sensitive arrays, content encodings and signature inputs. A cache-key fingerprint must also retain the security partition that prevents one principal's response from becoming another's.

Naming the answer changes the control surface

QUERY can produce something reusable beyond the immediate response. RFC 10008 defines an equivalent resource from the target resource, the request content and its metadata. An origin may assign that resource a URI, allowing a later GET. This can turn a long expression into a stable handle, make a result linkable or shift repeated retrieval onto familiar HTTP machinery.

But Location and Content-Location do not say the same thing. On a successful QUERY response, Location can identify an equivalent resource or query resource to retrieve later with GET. Content-Location identifies the URI corresponding to the returned representation under HTTP semantics. Treating either as a generic canonical URL erases the origin's claim about what was named.

The naming choice is also a disclosure choice. If the server embeds the original search, account identifier or confidential filter in the generated URI, it has moved data back into the surface QUERY was meant to avoid overloading. URIs pass through histories, logs, referrers and interfaces with different retention rules. Opaque names reduce that exposure, but they introduce lifecycle, access-control and revocation questions. A stable URI can outlive the authorization context in which the query was first evaluated.

RFC 3986 gives the identifier grammar. It cannot decide whether an assigned name should be public, guessable, durable or transferable. Those are origin policy decisions whose consequences reach clients and caches.

Redirects are method governance, not plumbing

QUERY deliberately removes a familiar ambiguity. For 301, 302, 307 and 308, the client preserves QUERY according to RFC 10008; the historical exceptions that can turn POST into GET do not apply. A 303 is the explicit transition to GET.

That distinction matters when request content is large or sensitive. Preserving QUERY sends the content to the new target; changing to GET addresses a resource instead. A gateway that rewrites methods out of habit can discard the query, expose it through a synthesized URI or accidentally route it into an unsafe handler. Every status has to be tested, including cross-origin redirects and credential stripping.

Conditional QUERY has a similarly exact reference point. Validators are evaluated against the selected representation that a GET to the equivalent resource would have selected. They are not just hashes attached to an arbitrary request body. If content negotiation, authorization or representation metadata changes the GET selection, the conditional query must follow the same model.

Capability is fresh, scoped evidence

Accept-Query advertises the media types an origin accepts for QUERY as an RFC 9651 Structured Fields List. RFC 10008 scopes the advertisement across resources sharing the same path while ignoring the URI query component, and makes the most recent fresh value the relevant signal.

That is deliberately less than a universal service contract. It says which formats the origin currently advertises at the relevant path. It does not prove that a particular expression is valid, that an intermediary caches QUERY, or that all nodes in a rollout agree. Operators need to observe the response that supplied the field, its freshness, path scope and the node or deployment version that produced it.

Browser use has another boundary. The Fetch Standard safelists GET, HEAD and POST, not QUERY. Cross-origin QUERY therefore requires a CORS preflight. Support at the origin is not sufficient if gateways reject the method, security policy omits it, or browser-facing CORS configuration does not authorize it.

Moving data out of the URI is not secrecy

QUERY can reduce one class of accidental exposure: complex parameters no longer have to occupy a GET URI merely to retain safe retrieval semantics. That may keep them out of URI-specific access logs, copied links and practical length limits. It is a useful architectural property, not a privacy guarantee.

The content still traverses the client, browser tooling, TLS termination, gateways, caches, observability systems and origin. Any of those can log, sample or retain it. A retry can transmit it twice. A redirect can send it to another authority. A generated equivalent-resource URI can re-expose it. A cache can store it or a derivative as part of its key.

Lu Heng's distinction between formal and practical data sovereignty applies directly. The origin formally defines the method semantics and supported media types. Practical custody is distributed across every participant that receives the content or its fingerprint. A governance inventory that marks only the origin as data holder describes the protocol contract, not the real path.

His minimum-specification and localized-decision model explains why the standard remains narrow. The common layer defines QUERY, cache obligations, redirect behavior and Accept-Query. Each origin chooses query languages, resource behavior and naming policy; each client decides whether to issue or retry; each capable cache decides whether it can preserve identity correctly. Shared interoperability does not require centralized application semantics.

And running-code primacy provides the evidentiary rule. The RFC can establish the expected contract. Only execution evidence can establish that the handler was safe, the repeated request was idempotent, the cache key included content, the redirect preserved method and the equivalent URI did not leak the query.

QUERY is valuable precisely because it makes these boundaries explicit. Its method token is not magic. It is a compact allocation of responsibility that becomes trustworthy only when each actor can prove the part it controls.