Integrating the HTTP QUERY method (RFC 10008): method normalization, CORS, and caching

[jeswr]

RFC 10008 defines QUERY: a safe, idempotent, cacheable method carrying a request body whose content defines the query. Scripted fetch(url, { method: 'QUERY', body }) already works — QUERY is neither a forbidden method nor normalized. A few Fetch integration points seem worth settling, and I'd like to gauge implementer interest:

1. Method normalization. "Normalize a method" uppercases only DELETE, GET, HEAD, OPTIONS, POST, and PUT, so fetch(url, { method: 'query' }) is sent as lowercase query, while the IANA-registered name is QUERY. Should QUERY be added to "normalize a method"?
2. CORS. QUERY is not CORS-safelisted, so a cross-origin QUERY triggers a preflight. RFC 10008 §4 expects this — just confirming it is the intended outcome (no safelist change sought).
3. Caching. RFC 10008 §2.7 makes a QUERY response cacheable with a cache key that incorporates the request content. Fetch's HTTP-cache model keys on the URL; should Fetch reflect body-keyed QUERY caching, or leave it to the HTTP cache layer? Empirically, current Chrome and Firefox both cache GET but neither caches a repeated identical QUERY, so there is no QUERY caching to rely on today.

This pairs with whatwg/html#12594 (declarative <form method="query">).

Implementations / interest so far: Node.js undici (nodejs/undici#5459; ships a body-aware cache key as a reference), Eclipse Jetty (jetty/jetty.project#15316), Apache Tomcat (apache/tomcat#1026); the W3C Linked Web Storage protocol is adopting QUERY (w3c/lws-protocol#179). Mainly seeking direction on whether and how Fetch should account for these, and which engines would be interested in implementing.

---

Companion standards-position requests: mozilla/standards-positions#1430 and WebKit/standards-positions#692.

Part of a broader RFC 10008 adoption effort: https://github.com/jeswr/http-query-adoption

[annevk]

1. No. Method names are case-sensitive.
2. It is.
3. Not sure. Maybe @mnot knows.

[mnot]

I'd say (3) is an area of research -- there's the obvious byte-for-byte approach, and various optimisations (as mentioned by the spec). Because HTTP caching is an optimisation itself, it's up to implementations as to how much they want to try here.