The HTTP Method That Should Have Existed Years Ago

RFC 10008 was published in June 2026. It introduces the QUERY HTTP method — safe, idempotent, cacheable, and unlike GET, it expects a request body.

Node.js, Go, and Laravel already support it. Browsers are adding support later this year.

This is not a minor convenience. It closes a gap that has been causing real architectural pain for anyone building complex read operations over HTTP, and ClawQL’s Ouroboros specification is a concrete example of what that pain looks like in production.

This pairs with Seven Surfaces, One Catalog, Memory Finds. Ontology Decides., and model escalation.

The problem QUERY solves

HTTP has always had a conceptual mismatch at the intersection of complex reads and request semantics.

GET is the right method for safe, idempotent, cacheable operations. A request that reads data without side effects should be GET. Proxies can cache it. CDNs can cache it. Clients can retry it safely. Prefetchers can hit it without consequences.

But GET cannot carry a request body. This is a problem the moment your query gets complex enough to need one — structured filters, nested conditions, multi-field predicates. The workarounds are all bad:

Stuff parameters into the URL. Works until you hit the length limit. Encoding nested JSON into query strings is ugly and breaks caching semantics because the URL becomes opaque to caching infrastructure.

Use POST. Solves the body problem but throws away all the safety semantics. POST is not idempotent. POST is not cacheable. Infrastructure treats POST differently — it gets retried differently, cached differently, handled differently by security tooling. A read operation expressed as POST is a lie to the HTTP layer.

Base64URL-encode the body and put it in a query parameter. This is what ClawQL’s Ouroboros advanced tier does for complex structured queries. It works. It is not pretty.

What Ouroboros has been working around

ClawQL’s Ouroboros specification implements a two-phase commit pattern for agent tool execution: stage via GET, confirm via POST.

The staging phase is a safe read — the agent queries what a tool would do, gets back a structured preview, and decides whether to proceed. This should be GET. It has no side effects. It is idempotent. It should be cacheable.

But staging a memory_recall with structured ontology filters looks like this:

GET /tools/memory_recall
  ?schema=legal.Matter
  &filters=eyJlc2Nyb3dQY3QiOnsiZ3RlIjoxMH0sIm5vbkNvbXBldGVNb250aHMiOnsiZ3QiOjE4fX0=

That Base64URL blob is {"escrowPct":{"gte":10},"nonCompeteMonths":{"gt":18}}. A perfectly reasonable structured filter expressed as gibberish in a URL because HTTP gave no other option.

The confirmation phase is POST. That’s correct — irreversible actions should be POST. The two-phase pattern exists because the staging read needed to be safe but couldn’t carry a body.

QUERY is the missing primitive

With QUERY, the staging phase becomes what it always should have been:

QUERY /tools/memory_recall
Content-Type: application/json

{
  "query": "matters with escrow and non-compete",
  "schema": "legal.Matter",
  "filters": {
    "escrowPct": { "gte": 10 },
    "nonCompeteMonths": { "gt": 18 }
  },
  "confidenceMinimum": "EXTRACTED"
}

Safe. Idempotent. Cacheable. The body carries the full structured filter without encoding. A CDN can cache this response keyed on the method, URL, and body. A prefetcher that hits it causes no side effects. Infrastructure treats it as a read because it is a read.

The POST confirmation stays exactly as it is. Irreversible actions require POST and that remains correct. QUERY only replaces the staging reads — the operations that were always logically safe but syntactically forced into POST (or into GET with an opaque encoded payload).

Where ClawQL adopts QUERY

Three places in the ClawQL stack where QUERY replaces existing workarounds:

mcp-api-adapter — read-only MCP tools (memory_recall, search, knowledge_search_onyx, audit_log_query) have been expressed as POST because that’s what MCP’s HTTP transport uses. These are semantically safe operations. They route through QUERY on the server-to-server surfaces. The /mcp-ui HTMX surface uses hx-method="QUERY" for read-only tool forms when the browser supports it, falling back to POST for compatibility.

Ouroboros staging phase — the Base64URL-encoded query parameter workaround in the advanced tier retires. Staging reads become QUERY with the full structured payload. The two-phase pattern simplifies: QUERY to stage, POST to confirm.

memory_recall structured filters — the ontology filter predicates are the most natural QUERY payload in the stack. A filter like { escrowPct: { gte: 10 }, nonCompeteMonths: { gt: 18 } } is exactly the kind of structured body that QUERY was designed for and exactly the kind of thing that has been awkward to express in GET parameters. See Memory Finds. Ontology Decides. for how those predicates earn their keep.

The timing

Browser support arrives later in 2026. Server-side support is already there — Node.js, Go, Laravel. ClawQL’s server-to-server surfaces (mcp-api-adapter’s gRPC, WebSocket, and Streamable HTTP surfaces, the Ouroboros coordination layer) can adopt QUERY now. The /mcp-ui browser surface follows when the browser implementation ships.

This is the adoption pattern for most HTTP method additions — server infrastructure leads, browsers follow. QUERY will be available everywhere within a year.

Catching up to the design

When a production system has been working around an absent primitive for long enough that the workarounds become part of the specification, and then the RFC that formalizes the primitive arrives, it feels less like a new feature and more like the infrastructure finally catching up to what the design always needed.

Ouroboros’s two-phase commit exists because HTTP didn’t have QUERY. Now it does. The workarounds retire cleanly and the semantics that were always intended become the semantics that are actually expressed.