Has Your Stack Noticed the QUERY Method Is Standard Now

On June 15, 2026, the IETF published RFC 10008: the HTTP QUERY method. It is the first new standard HTTP verb since PATCH in 2010, and it closes a gap that API designers have worked around for decades: a request that is safe and idempotent like GET, but carries a body like POST.

Plenty of articles already explain the RFC. This one does something different: it sends QUERY through a real 2026 stack, Node.js, fetch, Next.js, PHP, and records exactly what each layer does with it. The short version: the client side is ready, the server side mostly is not, and the failure modes range from a silent whitelist to a hard 501.

Why QUERY exists

Every API with non-trivial search has faced this choice:

• GET /search?filter=...: correct semantics (safe, cacheable, retryable), but query input lives in the URL: length limits, encoding pain, and sensitive criteria leaking into server logs, browser history, and Referer headers.
• POST /search: the body solves all of that, but the semantics are wrong: not safe, not idempotent, effectively uncacheable, and intermediaries won't auto-retry a failed request because POST promises nothing about side effects.

QUERY takes the body from POST and the semantics from GET:

Two spec details worth knowing before deploying anything:

• The cache key for a QUERY response must incorporate the request content. CDNs and reverse proxies need new logic before QUERY responses become cacheable in practice.
• QUERY is not CORS-safelisted. Browser requests will trigger a preflight OPTIONS. Plan for it.

The experiment

Versions tested: Node.js v22.11.0, Next.js 16.2.9, PHP 8.5.4 (built-in dev server), on Linux. Each test is reproducible with the commands shown.

Node.js: the parser already knows QUERY

node -e "console.log(require('http').METHODS.includes('QUERY'))"
# true

Node's HTTP parser (llhttp) accepts QUERY as a valid method token. A raw http.createServer receives the request and reports req.method === 'QUERY'. No flags, no configuration.

fetch: works end-to-end

const res = await fetch('http://127.0.0.1:3000/', {
  method: 'QUERY',
  body: '{"filter": {"status": "active"}}',
})

fetch (undici in Node, and the browser implementations) sends the method and the body without complaint. The server sees QUERY. The client side, the work is, for practical purposes, already done.

Next.js 16: a silent whitelist

Next.js App Router route handlers export functions named after HTTP methods. So the natural move is:

// app/api/search/route.ts
export async function QUERY(request: Request) { /* ... */ }

This does not work, and nothing tells you why. The list of methods Next.js will route is hardcoded in next/dist/server/web/http.js:

const HTTP_METHODS = [
    'GET',
    'HEAD',
    'OPTIONS',
    'POST',
    'PUT',
    'DELETE',
    'PATCH'
];

An exported QUERY function is simply never wired up. No error, no warning, no 405. Meanwhile, page routes respond 200 to a QUERY request as if it were a GET, which is its own semantic oddity.

PHP built-in server: a hard 501

php -S 127.0.0.1:8080 &
curl -X QUERY -d '{"q": 1}' http://127.0.0.1:8080/index.php

501 Not Implemented
Request method not supported.

The php -S development server rejects the method before your code runs. $_SERVER['REQUEST_METHOD'] never sees it. Production SAPIs (PHP-FPM behind nginx) pass unknown method tokens through to the application, so this is specifically a development-environment wall, the kind of asymmetry that makes a feature work in production and fail on every developer's machine.

.NET 10: the exception

For contrast: .NET 10 (LTS, November 2025) shipped with built-in QUERY support on both HttpClient and ASP.NET Core, the first major framework to do so. Two of the RFC's three authors, James Snell (Cloudflare) and Mike Bishop (Akamai), work at infrastructure companies with a direct stake in QUERY's cacheability story — which tracks with .NET's infrastructure-heavy customer base moving first.

What this means if you want QUERY today

You can accept it at the edge of your own Node servers right now — the parser and fetch are ready, frameworks are the missing layer. Advertise support with the RFC's Accept-Query response header so clients can feature-detect instead of guessing which query media types a resource accepts.

Keep the POST fallback around for years regardless. PATCH was standardized in 2010 and some frameworks still route it inconsistently; method adoption moves at the pace of the slowest middlebox. And budget for the CORS preflight — QUERY isn't safelisted, so a browser-based rollout doubles your request count until CDNs and browsers optimize for it.

I ran this whole experiment because a client asked why their Next.js API route silently ignored a QUERY request from a partner integration. The answer took twenty minutes to find once I knew where to look, and about two hours before that.

The RFC is the easy part. The interesting phase is the one we are in now: a correct, useful standard slowly negotiating with twenty years of deployed software that has never heard of it.

Try it yourself

Every test in this article is reproducible from a companion lab, versions pinned to the ones above, so it keeps demonstrating this exact snapshot even after newer releases change the picture:

npx degit imdela/log-labs/http-query my-lab
cd my-lab
./run-demo.sh

The script starts a raw Node server (which accepts QUERY and answers with filtered results), the Next.js app (405), and the PHP dev server in a container (501), sends the same request to all three, and prints what came back. The lab's README covers running each server by hand.

Delaa