DEV Community: Supratik Das

HTTP Just Got Its First New Request Method in Years — Meet QUERY

Supratik Das — Sat, 04 Jul 2026 16:49:11 +0000

If you've built APIs for any length of time, you've almost certainly hit this wall: you need to fetch data based on a complicated set of filters, but GET can't carry a body, and cramming a nested filter object into a query string turns into an unreadable, size-limited mess. So you reach for POST instead — and now your "read" operation looks like a "write" to every cache, proxy, and retry mechanism between your client and your server.

That mismatch has existed since the early days of HTTP. As of June 2026, it doesn't have to anymore.

The IETF has published RFC 10008: The HTTP QUERY Method as a Proposed Standard — the first genuinely new, general-purpose HTTP method to reach standardization in years. It was authored by Julian Reschke, James M. Snell (Cloudflare), and Mike Bishop (Akamai), and it gives the web a method that behaves like GET in terms of safety and cacheability, while carrying a request body like POST.

The problem QUERY was built to solve

HTTP developers have historically had exactly two tools for "give me data based on these parameters," and neither one is quite right.

GET puts everything in the URI. That's semantically clean — the resource is fully identified by the URL, so caching, bookmarking, and safe retries all just work. But it falls apart once your query gets complex:

There's no reliable, agreed-upon size limit. A request might pass through several intermediaries that each impose their own cap, and RFC 9110 only recommends 8,000 octets as a rough floor — not a guarantee.
Structured data — nested filters, arbitrary JSON — is awkward and expensive to squeeze into a URL-safe string. Anyone who's base64-encoded a JSON blob into a query parameter knows the pain.
URIs get logged, cached by browsers, and passed around far more casually than request bodies do, which becomes a real problem the moment your query includes anything sensitive.
Every distinct set of parameters is technically a distinct resource, which is rarely what you actually mean semantically.

POST solves the size and encoding problems, since the payload lives in the body instead of the URL. But it throws away the one property that made GET useful: nothing in HTTP's method semantics tells a cache, proxy, or client whether a given POST is safe to retry or safe to cache. Some POST endpoints mutate state, some don't — and HTTP itself can't tell the difference, so every intermediary has to assume the worst.

The workaround many APIs settled on — a GET/POST/GET dance to search, materialize a result resource, then fetch it — was really just people improvising a method that HTTP didn't have.

What QUERY actually does

QUERY takes the request semantics of GET and pairs them with the request-body mechanics of POST. Here's the comparison at a glance:

	GET	QUERY	POST
Safe	Yes	Yes	Not guaranteed
Idempotent	Yes	Yes	Not guaranteed
Query lives in the URI	Yes, by definition	Optional	No
Cacheable	Yes	Yes	Only for a subsequent GET/HEAD
Request body	No defined semantics	Expected	Expected

A QUERY request targets a resource (via the URI, same as GET) and encloses content describing how that resource should be queried — arbitrary JSON, SQL, GraphQL, XML, whatever the server is willing to accept. The server processes that content safely and idempotently, then returns the result.

Because QUERY is registered in the IANA HTTP Method Registry as both safe and idempotent, this isn't something you have to document in your API reference and hope people read — any generic HTTP client, proxy, or cache can treat QUERY requests correctly without knowing anything specific about your API. Retrying a QUERY after a network hiccup is always safe, exactly like retrying a GET.

A basic QUERY request

QUERY /products HTTP/1.1
Host: shop.example.com
Content-Type: application/json
Accept: application/json

{
  "filter": {
    "category": "electronics",
    "price": { "lt": 500 },
    "inStock": true
  },
  "sort": "-rating",
  "limit": 20
}

The server responds the same way it would to any successful GET — a 200 OK with the representation the client asked for.

Accept-Query: telling clients what you speak

Since a QUERY body's meaning depends entirely on its Content-Type — unlike WebDAV's older safe-body methods (PROPFIND, REPORT, SEARCH), which are all tied to a single XML media type — a server needs a way to advertise which query languages it actually understands. That's what the new Accept-Query response header is for:

Accept-Query: "application/jsonpath", application/sql;charset="UTF-8"

A client can send a HEAD or OPTIONS request first, read Accept-Query, and pick a format the server supports — instead of guessing and getting back a 415 Unsupported Media Type.

Location vs. Content-Location: don't mix these up

RFC 10008 introduces the idea of an "equivalent resource" — a conceptual resource derived from the target URI plus the request content. A server can expose that resource through two different headers, and confusing them is the most common mistake teams are likely to make:

Content-Location points to a snapshot of this specific result. It's useful for caching the answer to a query that already happened.
Location points to a URI the client can GET later to repeat this exact query without resending the body. It turns an expensive QUERY into a cheap, cacheable GET for next time.

Mix these up and your caching layer will start serving stale results or the wrong data entirely — Content-Location is a snapshot, Location is a live, repeatable query.

Caching a body is harder than caching a URL

This is the part of the spec worth reading twice if you run a CDN or reverse proxy. A QUERY response is cacheable, but the cache key has to incorporate the entire normalized request body, not just the URI. That means a cache has to read and normalize the whole payload before it can even check for a hit — normalizing away things like content-encoding differences or JSON key ordering, but only in ways that don't change how the server actually interprets the query. Get the normalization wrong and you'll get false-positive cache hits, which the spec's Security Considerations section calls out explicitly as a real risk, not a theoretical one.

The catch: CORS preflights

If you're calling a QUERY endpoint from browser JavaScript, there's one thing to plan for: QUERY is not on the CORS-safelisted method list. Every cross-origin QUERY call will trigger an OPTIONS preflight first, exactly like a POST with a non-simple Content-Type already does today. It's rarely a reason to avoid QUERY, but it is a reason not to be surprised when your network waterfall grows an extra round trip on hot paths.

Where things stand today

Publishing a Proposed Standard doesn't mean the whole ecosystem wakes up supporting it the next morning. As of mid-2026:

No major browser implements QUERY natively yet. You can't currently send it from fetch() or XMLHttpRequest — this has been an open, actively discussed request against browser fetch implementations, since browsers generally allow arbitrary method names but the ergonomics for a genuinely new safe method with a body still need to be worked out across engines.
Server frameworks are catching up faster. Runtimes and languages that let you match arbitrary method strings — Go's net/http with its 1.22+ method-aware routing, for instance — can support QUERY today with no changes needed, since the method name is just a string to them. Node.js's http module has had community interest and active discussion around first-class support for the method as well.
.NET 10 (LTS, released November 2025) is among the first major platforms to ship built-in QUERY support on both the client and server side, including a dedicated HttpMethod.Query on the client.
Proxies and CDNs don't yet cache QUERY responses at scale by default — though the fact that two of the RFC's three authors work at Cloudflare and Akamai is a fairly strong signal about where that's headed.

A sane way to roll it out

Given where adoption stands, treat QUERY as an addition, not a replacement — at least for now:

Keep your existing POST-based search or filter endpoint in place.
Add a QUERY handler alongside it that accepts the same content shape.
Advertise supported query formats via Accept-Query.
Let clients migrate to QUERY as their tooling — SDKs, browsers, corporate proxies with method allow-lists — catches up.

That gives you the correct semantics for the clients that already understand QUERY, without breaking anything for the ones that don't.

Why this matters

QUERY isn't a flashy addition — it's a plumbing fix. It closes a hole in HTTP's method vocabulary that's been there since the protocol's earliest days, and it does it in a way that's mechanically enforceable by generic infrastructure rather than something you have to explain in your API docs and hope developers respect. If you maintain an API with a search or filter endpoint that outgrew GET years ago and settled uneasily into POST, this is the method that endpoint always should have had.

It'll take time for browsers, proxies, and client libraries to fully catch up. But for server-side APIs, service-to-service calls, and any client stack that already supports arbitrary HTTP methods, there's nothing stopping you from adding QUERY support today.

Further reading: RFC 10008 — The HTTP QUERY Method at the RFC Editor.

[Boost]

Supratik Das — Fri, 26 Jun 2026 16:11:21 +0000

Supratik Das

Jun 25

Why Do Promises Run Before setTimeout? (Explained Visually)

#javascript #webdev #beginners #tutorial

4 min read

Why Do Promises Run Before setTimeout? (Explained Visually)

Supratik Das — Thu, 25 Jun 2026 16:45:11 +0000

Almost every JavaScript developer has seen this:

console.log("Start");

setTimeout(() => {
  console.log("setTimeout");
}, 0);

Promise.resolve().then(() => {
  console.log("Promise");
});

console.log("End");

Output

Start
End
Promise
setTimeout

At first glance, this seems strange.

setTimeout(..., 0) looks like it should execute immediately. So why does the Promise callback run first?

The answer lies in JavaScript's Event Loop.

👉 Run this in JS Visualizer — watch the queues in real time

Step 1: JavaScript Executes Synchronous Code First

Everything in the current script executes on the Call Stack.

console.log("Start");

prints immediately.

When JavaScript encounters:

setTimeout(() => {
  console.log("setTimeout");
}, 0);

it does not execute the callback.

Instead, it hands the callback to the browser (or Node.js) timer system and continues executing the current script.

Promise.resolve().then(() => {
  console.log("Promise");
});

The Promise is already resolved, so its .then() callback is immediately scheduled in the Microtask Queue.

Finally:

console.log("End");

prints.

Current output:

Start
End

Step 2: The Call Stack Becomes Empty

At this point:

Microtask Queue
---------------
Promise callback

Task Queue (Macrotask Queue)
----------------------------
setTimeout callback

Step 3: The Event Loop Rule

The Event Loop always follows this order:

Execute one Task (current script).
Empty the entire Microtask Queue.
Optionally allow rendering.
Execute the next Task (Macrotask).

Because Promise callbacks are Microtasks, they execute before timer callbacks.

Output now becomes:

Start
End
Promise

Step 4: Finally, `setTimeout` Runs

After the Microtask Queue is empty, the Event Loop processes the next Task:

setTimeout

Final output:

Start
End
Promise
setTimeout

Common Misconception

❌ Promises have higher priority than setTimeout.

This is an oversimplification.

✅ The real reason is:

The Event Loop must completely drain the Microtask Queue before executing the next Task (Macrotask).

Why Doesn't `setTimeout(0)` Run Immediately?

setTimeout(fn, 0) means:

Execute after at least 0 milliseconds.

It does not mean "execute instantly."

Even after the timer expires, its callback waits until:

The current script finishes.
The Call Stack becomes empty.
Every pending Microtask has completed.

Visual Timeline

Current Script
│
├── console.log("Start")
├── setTimeout(...)  ─────► Browser Timer
├── Promise.then() ───────► Microtask Queue
└── console.log("End")

Call Stack Empty
        │
        ▼
Drain ALL Microtasks
        │
        ▼
Promise callback

        ▼
Run Next Task
        │
        ▼
setTimeout callback

Example 2

console.log(1);

setTimeout(() => console.log(2), 0);

Promise.resolve()
  .then(() => console.log(3))
  .then(() => console.log(4));

console.log(5);

Output

Why?

Synchronous → 1, 5
Microtasks  → 3, 4
Tasks       → 2

The second .then() is also a Microtask, so it executes before setTimeout.

👉 Run Example 2 in JS Visualizer

Example 3

console.log("Start");

setTimeout(() => {
  console.log("Timeout");
}, 0);

Promise.resolve().then(() => {
  console.log("Promise 1");

  Promise.resolve().then(() => {
    console.log("Promise 2");
  });
});

console.log("End");

Output

Start
End
Promise 1
Promise 2
Timeout

While executing Promise 1, another Microtask is scheduled. The Event Loop continues draining Microtasks until none remain.

👉 Run Example 3 in JS Visualizer

Microtask Starvation

function loop() {
  Promise.resolve().then(loop);
}

loop();

Because every Microtask schedules another Microtask:

setTimeout never executes.
Rendering may be blocked.
The application appears frozen.

This is called Microtask Starvation.

👉 Run Microtask Starvation in JS Visualizer

Note: The starvation example uses a counter limit so it doesn't actually freeze your browser — but you'll see all microtasks drain before the setTimeout fires.

Mental Model

Current Script
      ↓
Drain ALL Microtasks
      ↓
Browser may Render
      ↓
Run ONE Task
      ↓
Repeat

Key Takeaways

setTimeout(..., 0) schedules a Task (Macrotask) after at least the specified delay.
Promise callbacks (then, catch, finally) are Microtasks.
The Event Loop always drains the entire Microtask Queue before processing the next Task.
This is why Promises execute before setTimeout().
Microtasks can enqueue more Microtasks, and they all finish before the next Task.

Want to see all of this animate live? Open JS Visualizer — free, no signup and step through any example above.

JavaScript Event Loop Explained — A Visual, Step-by-Step Guide

Supratik Das — Sat, 06 Jun 2026 19:22:47 +0000

Ask ten developers how the JavaScript event loop works, and you'll get eleven different answers. That's because the event loop is invisible. You can't console.log it. You can't set a breakpoint on it. You just have to know it's there, orchestrating everything.

This guide changes that. We'll walk through the event loop step by step, with code you can actually run and see in JS Visualizer — watching functions enter the call stack, callbacks move through Web APIs, and promises flush from the microtask queue.

The Puzzle That Trips Everyone Up

Before we dive in, try to predict the output of this code:

console.log('A');

setTimeout(() => console.log('B'), 0);

Promise.resolve().then(() => console.log('C'));

console.log('D');

Most beginners guess A, B, C, D. The actual output is:

A
D
C
B

If that surprises you, you're in exactly the right place. By the end of this article, you'll understand why — and it will feel obvious.

👉 Run this puzzle in JS Visualizer

The JavaScript Runtime: Four Moving Parts

JavaScript's runtime has four key components:

Component	Role
Call Stack	Where functions execute. One at a time — JS is single-threaded.
Web APIs	Browser features (setTimeout, fetch, DOM events) running outside the main thread.
Task Queue	Callbacks from Web APIs waiting for the call stack to empty.
Microtask Queue	Promise callbacks. Always processed before the task queue.

And then there's the event loop itself — the coordinator. Its job: when the call stack is empty, pick the next thing to run.

Step 1: The Call Stack — One Thing at a Time

JavaScript is single-threaded. It has one call stack and can do one thing at a time. When you call a function, it gets pushed onto the stack. When it returns, it gets popped off.

function greet(name) {
  return 'Hello, ' + name;
}

function processUser(name) {
  const message = greet(name);
  console.log(message);
}

processUser('Supratik');

Here's what happens on the call stack:

processUser('Supratik') is pushed onto the stack
Inside it, greet('Supratik') is pushed on top
greet returns → popped off the stack
console.log(message) is pushed, executes, popped
processUser returns → popped off. Stack is empty.

💡 The call stack is like a stack of plates. You can only add or remove from the top. If a function calls another function, the new one goes on top and must finish before we return to the one below it.

Step 2: Web APIs — Where Async Things Wait

When you call setTimeout, fetch, or add a DOM event listener, JavaScript doesn't handle the waiting itself. It hands the job off to Web APIs — features provided by the browser (or Node.js runtime).

console.log('Start');

setTimeout(() => {
  console.log('Timer done');
}, 2000);

console.log('End');

Here's the flow:

console.log('Start') → runs immediately on the call stack
setTimeout → registers the callback with the Web API. The timer starts counting outside the call stack. setTimeout itself returns immediately.
console.log('End') → runs immediately
After 2000ms, the Web API moves the callback to the task queue
The event loop sees the call stack is empty → picks the callback → runs it

Output: Start → End → Timer done. The timer callback runs last, even though it was registered second.

👉 Watch the timer move through Web APIs

Step 3: The Task Queue (Macrotask Queue)

When a Web API finishes its work (timer expires, fetch returns, click happens), it doesn't interrupt whatever's currently running. Instead, it places the callback in the task queue (also called the macrotask queue).

The event loop's rule is simple: when the call stack is empty, take the first task from the queue and push it onto the stack.

setTimeout(() => console.log('First timeout'), 0);
setTimeout(() => console.log('Second timeout'), 0);

console.log('Synchronous');

Output: Synchronous → First timeout → Second timeout. Both timeouts go to the task queue, and they're processed in order — but only after all synchronous code finishes.

⚠️ Common mistake: setTimeout(fn, 0) does NOT mean "run immediately." It means "run as soon as the call stack is empty and you get to the front of the queue." If there's a lot of synchronous code running, the 0ms timer could wait hundreds of milliseconds.

Step 4: The Microtask Queue — Promises Jump the Line

This is where most developers get confused. There are actually two queues, and one has priority over the other.

The microtask queue holds callbacks from:

Promise.then(), .catch(), .finally()
queueMicrotask()
MutationObserver

The critical rule: the event loop drains the entire microtask queue before touching the task queue. Every. Single. Time. If a microtask adds another microtask, that runs too — before any setTimeout callback gets a chance.

setTimeout(() => console.log('Macrotask'), 0);

Promise.resolve().then(() => console.log('Microtask 1'));
Promise.resolve().then(() => console.log('Microtask 2'));

console.log('Synchronous');

Output:

Synchronous
Microtask 1
Microtask 2
Macrotask

Even though setTimeout was registered first, both Promise callbacks run before it. The microtask queue always gets priority.

👉 Watch microtasks jump the line

Step 5: The Event Loop Algorithm

Now we can state the event loop's actual algorithm:

Run all synchronous code on the call stack until it's empty.
Drain the entire microtask queue. If any microtask adds new microtasks, drain those too.
Take one task from the task queue and push it onto the call stack.
Go back to step 2. (Yes — microtasks are checked again after every single macrotask.)

That's it. The entire event loop is these four steps, on repeat, forever.

Solving the Original Puzzle

Now let's go back to our puzzle and trace through it:

console.log('A');           // 1. Synchronous → runs immediately
setTimeout(() =>
  console.log('B'), 0);     // 2. Registers with Web API → callback goes to TASK queue
Promise.resolve().then(()
  => console.log('C'));     // 3. Already resolved → callback goes to MICROTASK queue
console.log('D');           // 4. Synchronous → runs immediately

Step by step:

console.log('A') → prints A
setTimeout → callback sent to Web API → moves to task queue
Promise.resolve().then() → already resolved → callback goes to microtask queue
console.log('D') → prints D
Call stack is empty → drain microtask queue → console.log('C') → prints C
Microtask queue empty → take from task queue → console.log('B') → prints B

Final output: A, D, C, B. Mystery solved.

Bonus: How async/await Fits In

async/await is just syntactic sugar over Promises. When you await something, everything after the await becomes a microtask.

async function demo() {
  console.log('Before await');
  await Promise.resolve();
  console.log('After await');  // This is a microtask!
}

console.log('Start');
demo();
console.log('End');

Output:

Start
Before await
End
After await

"After await" runs as a microtask — same as if you'd written Promise.resolve().then(() => console.log('After await')).

👉 See async/await as microtasks

Common Mistakes and Misconceptions

❌ Myth: setTimeout(fn, 0) runs immediately
It runs after all synchronous code AND all microtasks. The 0 is a minimum delay, not a guarantee.

❌ Myth: Promises are asynchronous
The Promise constructor runs synchronously. Only the .then() callback is deferred (as a microtask).

❌ Myth: JavaScript is multi-threaded because it can do async things
JavaScript itself is single-threaded. Web APIs (provided by the browser) can run in parallel, but your JS code always runs one line at a time on one call stack.

Summary

JavaScript has one call stack — it's single-threaded.
Async operations (timers, network) are handled by Web APIs outside the main thread.
When Web APIs finish, callbacks go to the task queue (macrotask queue).
Promise callbacks go to the microtask queue, which has higher priority.
The event loop: run sync code → drain all microtasks → pick one macrotask → repeat.
async/await is syntactic sugar — everything after await becomes a microtask.

The best way to internalize this? See it happen. Open JS Visualizer, paste any code snippet from this article, and watch every step unfold across the call stack, queues, and event loop — in real time. It's free.

Try JS Visualizer — Free

DEV Community: Supratik Das

HTTP Just Got Its First New Request Method in Years — Meet QUERY

The problem QUERY was built to solve

What QUERY actually does

A basic QUERY request

Accept-Query: telling clients what you speak

Location vs. Content-Location: don't mix these up

Caching a body is harder than caching a URL

The catch: CORS preflights

Where things stand today

A sane way to roll it out

Why this matters

[Boost]

Why Do Promises Run Before setTimeout? (Explained Visually)

Why Do Promises Run Before setTimeout? (Explained Visually)

Step 1: JavaScript Executes Synchronous Code First

Step 2: The Call Stack Becomes Empty

Step 3: The Event Loop Rule

Step 4: Finally, setTimeout Runs

Common Misconception

Why Doesn't setTimeout(0) Run Immediately?

Visual Timeline

Example 2

Why?

Example 3

Microtask Starvation

Mental Model

Key Takeaways

JavaScript Event Loop Explained — A Visual, Step-by-Step Guide

The Puzzle That Trips Everyone Up

The JavaScript Runtime: Four Moving Parts

Step 1: The Call Stack — One Thing at a Time

Step 2: Web APIs — Where Async Things Wait

Step 3: The Task Queue (Macrotask Queue)

Step 4: The Microtask Queue — Promises Jump the Line

Step 5: The Event Loop Algorithm

Solving the Original Puzzle

Bonus: How async/await Fits In

Common Mistakes and Misconceptions

Summary

Step 4: Finally, `setTimeout` Runs

Why Doesn't `setTimeout(0)` Run Immediately?