Does Your Stack Support HTTP QUERY Yet?
A maintained compatibility matrix for RFC 10008's HTTP QUERY method across frameworks, proxies, and clients. Search or filter the table below. Data last reviewed 2026-07-07.
How HTTP QUERY Support Matrix works
Browse or search the table
Type a framework, proxy, or client name into the search box, or leave it blank to see every entry. The search matches against the name, the note, and the status label.
Filter by category
Use the category tabs to narrow the table to Web Frameworks, Proxies / CDNs, or HTTP Clients only, so you can check one layer of your stack at a time.
Read the status badge
Each row shows a status: Supported, Partial, Not Yet, or Unknown, based on a manual review of the project's documentation and issue tracker at the time it was last verified.
Check the note and version/date
The note explains what the status actually means in practice, for example whether a workaround exists, and the version or date column shows when native support landed, where applicable.
Follow the source link to verify
Every entry links to its authoritative source, a GitHub issue, official documentation, or changelog, along with the date it was last verified, so you can confirm the current status yourself rather than take a snapshot on faith.
What each status means
Native support for QUERY is confirmed, either the project's own core parses or routes the method directly, or its documented default behavior passes the method through without extra configuration.
QUERY can be made to work today, but only with a manual workaround, an in-progress pull request, or inconsistent behavior across implementations or environments.
A confirmed limitation exists. The project's routing or method handling does not recognize QUERY as a standard verb, and no documented workaround was found at time of review.
No confirmed status could be established from available documentation as of the last review date. This is not the same as "broken", it means the specific behavior needs to be verified against the project's current release.
Table reference
Every row in the matrix follows the same structure. Here is what each column means:
| Column | Meaning |
|---|---|
| Name | The framework, proxy/CDN, or client being tracked. |
| Status | One of Supported, Partial, Not Yet, or Unknown, defined in the section above. |
| Version / Date | The version number or date native support landed, where a specific one is documented. |
| Note | A short explanation of what the status means in practice for that specific entry, including any workaround. |
| Source | A link to the authoritative source (GitHub issue, official docs, or changelog) plus the date that source was last checked. |
When to use HTTP QUERY Support Matrix
| Scenario | What to check |
|---|---|
| Deciding whether to adopt QUERY for a new search endpoint | Your web framework's status, plus any proxy or CDN in front of your API |
| Building a public API called from browsers | The fetch() row under HTTP Clients, since browser support is the most inconsistent layer |
| Running behind Cloudflare, Akamai, or an AWS ALB | The relevant Proxies / CDNs row for passthrough or caching behavior |
| Reviewing a PR that adds a QUERY route | Your framework's status to confirm whether the workaround pattern used matches current best practice |
| Choosing between Postman, Insomnia, or curl for manual testing | The HTTP Clients rows to confirm which tool supports typing a custom method |
| Revisiting an old decision to skip QUERY six months ago | The status and last verified date for your specific framework, since support evolves quickly |
Frequently Asked Questions
What is HTTP QUERY Support Matrix and what does it show?
HTTP QUERY Support Matrix is a browsable, filterable reference showing current support status for the HTTP QUERY method (RFC 10008) across web frameworks (Express, Fastify, Hono, Rails, Spring, Django, ASP.NET Core, and Node.js core), reverse proxies and CDNs (nginx, Cloudflare, Akamai, Vercel, AWS ALB), and HTTP clients (curl, fetch, Postman, Insomnia, axios).
Each entry shows a support status, the version or date support landed where applicable, a short note explaining the current state, and a link to the authoritative source, a GitHub issue, official docs, or changelog, so you can verify the claim yourself rather than take it on faith.
How is this different from caniuse.com or checking GitHub issues directly?
| HTTP QUERY Support Matrix | caniuse.com / individual GitHub issues | |
|---|---|---|
| Covers server-side frameworks | Yes | No, caniuse.com is browser-focused; issues are scattered one repo at a time |
| Covers proxies/CDNs | Yes | No single consolidated source |
| Covers HTTP clients | Yes | Partially, browser-only on caniuse.com |
| One place to check your whole stack | Yes | No, requires checking each project's tracker separately |
| Links to authoritative sources | Yes, per entry | N/A, is the source |
caniuse.com is the gold standard for browser feature compatibility, but HTTP QUERY as a server-side method is outside its typical scope. Individual GitHub tracking issues, like nodejs/node#51562 and expressjs/express#5615, are accurate and authoritative, but scattered across dozens of separate repositories with no single place to check status across your entire stack at once. This tool consolidates that into one filterable table.
Does this tool send any data to a server?
No. The compatibility dataset is a static, manually curated list bundled directly into the page. Searching and filtering happen entirely in your browser with plain JavaScript array operations. There is no backend, no API call, and no data collected about what you search for.
How do I check whether my specific stack is ready to adopt QUERY?
Use the category tabs to narrow to Web Frameworks, Proxies / CDNs, or HTTP Clients, then search for the specific piece of your stack, for example your framework, your CDN, and the clients calling your API. Check all three layers before committing, since a request can fail at any point along the path even if your framework itself supports QUERY.
Example: an Express API behind Cloudflare, called from a browser
1. Search "Express" under Web Frameworks -> Partial, manual workaround required
2. Search "Cloudflare" under Proxies / CDNs -> verify current passthrough behavior
3. Search "fetch" under HTTP Clients -> Partial, inconsistent across browser engines
All three need to work for a QUERY request to succeed end to end.For the actual Express workaround code, see the companion guide on implementing HTTP QUERY in Express and Node.js.
How often is this data updated, and what if it's wrong or out of date?
This is a manually maintained snapshot, not a live-updating feed pulled from each project's API. Every entry carries its own "last verified" date, and the page shows an overall "data last reviewed" date, so you can judge how current the information is before relying on it.
What's the difference between "Not Yet" and "Unknown" status?
"Not Yet" means there is a confirmed limitation: the framework or proxy has been checked and does not currently support QUERY without a workaround, or actively rejects it. "Unknown" means no confirmed status could be established as of the last review, either because the project's documentation doesn't address it directly or because behavior needs to be verified against the current release before it can be marked with confidence. Treat "Unknown" as a prompt to verify yourself against current docs, not as a claim that it doesn't work.