Support QUERY method in form submissions

[chris-morgan]

(<form method="query"> and formmethod="query".)

After many years of waiting, RFC 10008: The HTTP QUERY Method has been published.

It seems reasonable to me to add it to HTML. (I’m no browser maker, but I hope they agree too.) Being able to get rid of the “are you sure you want to resend the request?” warning you get from using POST would be nice.

I’ve already made a patch because I was curious to go through and see where I reckoned modifications might be needed, but I submit this as an issue because the thing is unsolicited and I also doubt the patch is ready as-is—“POST resource” really wants a new name, and I don’t know if Fetch needs corresponding changes (e.g. should QUERY be a CORS-safelisted method, and are there implications, one way or another, to form submissions), and there are probably more things that experts/implementers should consider that I haven’t thought of.

Related: #3577, #11347 (issue and PR for supporting PUT/PATCH/DELETE).

[samuel-ifrs]

A few use cases, a note on encoding, and a live repro — including a real-world infra gotcha.

Why QUERY is a particularly good fit for forms

Because QUERY is safe and idempotent, a <form method="query"> submission would — unlike POST — be safely bookmarkable, re-runnable on back/forward navigation, and cacheable, while still carrying a request body. That fills a real gap, where complex read requests are forced into one of two imperfect options:

• GET with a long query string → URL length limits, awkward for nested/structured criteria.
• POST used for a read → semantically wrong; breaks caching, the back button, and link sharing.

Concrete use cases: faceted/advanced search, report builders, map bounding-box queries, and structured-query endpoints (e.g. GraphQL) driven by a plain HTML form with no JavaScript.

On the open encoding question

The natural default would be to reuse existing form serialization — application/x-www-form-urlencoded (and multipart/form-data via enctype) — placed in the request body instead of the URL. That keeps the authoring model identical to today's forms; the only change is where the bytes go. Worth deciding whether/how Accept-Query (RFC 10008) interacts with this.

Relationship to #3577 / #11347 (PUT/PATCH/DELETE in forms)

I'd argue QUERY should be considered separately and is the easier case. PUT/PATCH/DELETE are unsafe and raise real CORS/security questions for form submission. QUERY is safe + idempotent, so it sidesteps most of those — it's much closer to GET, just with a body. A lower-risk first step.

Live repro of current behavior

Demo (no install): https://samuel-ifrs.github.io/query-form-repro/
Source + Node version: https://github.com/samuel-ifrs/query-form-repro

• The method="query" form reaches the server as GET — the body is silently dropped, because an unknown form method falls back to GET. (The get/post controls behave as expected.)
• fetch(url, { method: 'QUERY', body }) does send QUERY on the wire (the Node server logs actual=QUERY same-origin), so the method is already reachable from script — just not from declarative forms.

One infra data point worth flagging for rollout

While building the repro I tried hosting the echo endpoint behind LiteSpeed (a very common web server): it rejects QUERY at the request parser with 400 "It is not a valid request!" — before the app runs, and not fixable via .htaccess/WAF config. So even where the browser side lands, end-to-end QUERY will depend on server/WAF stacks recognizing the method. Not a blocker for this issue, but relevant to how broadly <form method="query"> would actually work in the wild today.

Happy to help flesh out a spec PR for the form-submission side if there's implementer interest.

[alexpetros]

@chris-morgan:

I’ve already made a patch because I was curious to go through and see where I reckoned modifications might be needed, but I submit this as an issue because the thing is unsolicited and I also doubt the patch is ready as-is—“POST resource” really wants a new name,

The spec change in #11347 handles the "POST resource" naming issue! If WHATWG were interested, I would be happy to refactor it out of my PR and merge it separately.

@samuel-ifrs:

PUT/PATCH/DELETE are unsafe and raise real CORS/security questions for form submission.

As implemented in #11347, proposal #3577 does not raise any CORS concerns because PUT, PATCH, and DELETE methods are CORS-enabled by default; they're actually safer than the existing POST forms, which have CORS exceptions. If you have some other security concern in mind, though, please do call it out on the issue tracker.