Support the HTTP QUERY method (RFC 10008) in @RequestMapping / RequestMethod

[jeswr]

RFC 10008 (Proposed Standard; IANA-registered) defines QUERY — a safe, idempotent, cacheable HTTP method carrying a request body whose content defines the query.

Problem: Spring MVC / WebFlux route declarations select on the RequestMethod enum (GET/HEAD/POST/PUT/PATCH/DELETE/OPTIONS/TRACE) via @RequestMapping(method = …) and the @GetMapping/@PostMapping shortcuts. There is no RequestMethod.QUERY, so a handler cannot be declaratively mapped to QUERY — the alternatives are matching all methods and inspecting request.getMethod(), or a custom RequestMappingHandlerMapping.

Ask: add RequestMethod.QUERY (and a way to declare it, e.g. @RequestMapping(method = RequestMethod.QUERY)), routed through the request-mapping infrastructure, with the handler able to read the request body, and treated as safe/idempotent where the framework branches on method. (Note: the obvious shortcut name @QueryMapping is already taken by Spring GraphQL, so a different name or plain @RequestMapping would be needed.)

Context: QUERY support is emerging across the ecosystem — Node's undici (nodejs/undici#5459), Eclipse Jetty (jetty/jetty.project#15316), Apache Tomcat (apache/tomcat#1026); and the W3C Linked Web Storage protocol is adopting it (w3c/lws-protocol#179).

---

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

[hiSandog]

Supporting HTTP QUERY likely touches more than RequestMethod. It may also need coverage in request mapping condition parsing, client-side APIs such as WebClient/RestClient, and server adapters that validate method tokens. It would be helpful to decide whether Spring should expose QUERY as a first-class enum value or document a generic custom-method path for newer RFC methods.

[desiderantes]

I have a PR for this already, I'd appreciate any suggestions: #34993