PSA: When posting an RFC or (especially) an RFC-draft, please use the IETF Datatracker URL.
For example, this one is: https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-met...
The best way to view an RFC, IMHO, is to use the "htmlized" format: you can view and compare different versions, view errata for a formal RFC, and go back to Datatracker at any time.
Also, the Datatracker URL is version-insensitive, so unlike the pure HTML format, it will not be stuck on draft-14 forever.
I can’t wait for QUERY to become an official RFC.
It's felt quite awkward to tiptoe around the existing spec when building features that retrieve data; we've had to either use POST to keep sensitive filter criteria out of http logs or just create a usually massive URL-encoded query string.
There's nothing holding you back implementing the QUERY method right now - HTTP methods are standardized, but not limited to the standard. Obsviously it depends how proxies/servers/etc. might handle uncommon methods.
But that's the point, isn't it? Browsers, proxies and servers always assume POST isn't idempotent. When the user presses F5 the browser asks if they want to do the thing again. You can't prevent that without making it more complicated (e.g. send the request from JavaScript).
> There's nothing holding you back implementing the QUERY method right now - HTTP methods are standardized, but not limited to the standard.
I think this comment is terribly naive. Technically you can write your own service to support verbs like LOL or FUBAR, but in practice your service is not only expected to be broken when passing requests through other participants you do not control but also it requires far more development work to integrate with existing standards. Take for example CORS. If a HTTP method is not deemed safe then client requests need to go through the unsafe flow with preflight requests and the like. Forget support for caching too, and good luck having your requests pass through proxies.
So what exactly did you achieved by using non-standard verbs?
If you chose to go the ignorant backwards incompatible way, you are better off not using HTTP at all and just go with some random messaging/RPC protocol.
I won't be so strict. Even though a homebrew implementation won't be widely interoperable, an experience of its active development and use in a limited environment (e.g. within a company) would be valuable both to inform the RFC and to serve an example implementation.
Very timely as I just recently ended up with a URL query string so big that CloudFront rejected the request before it even hit my server.. Ended up switching that endpoint to POST. Would've liked QUERY for that!
I have come across systems that use GET but with a payload like POST.
This allows the GET to bypass the 4k URL limit.
It's not a common pattern, and QUERY is a nice way to differentiate it (and, I suspect will be more compatible with Middleware).
I have a suspicion that quite a few servers support this pattern (as does my own) but not many programmers are aware of it, so it's very infrequently used.
Sending a GET request with a body is just asking for all sorts of weird caching and processing issues.
To be clear, it's less of a "suggestion" and more of a report of something I've come across in the wild.
And as much as it may disregard the RFC, that's not a convincing argument for the customer who is looking to interact with a specific server that requires it.
Cache in web middleware like Apache or nginx by default ignores GET request body, which may lead to bugs and security vulnerabilities.
> I have come across systems that use GET but with a payload like POST.
I think that violates the HTTP spec. RFC 9110 is very clear that content sent in a GET request cannot be used.
Even if both clients and servers are somehow implemented to ignore HTTP specs and still send and receive content in GET requests, the RFC specs are very clear that participants in HTTP connections, such as proxies, are not aware of this abuse and can and often do strip request bodies. These are not hypotheticals.
Elasticsearch comes to mind.[0]
The docs state that is query is in the URL parameters, that will be used.I remember that a few years back it wasn't as easy - you HAD to send the query in the GET requests body. (Or it could have been that I had a monster queries that didn't fit through the URL character limits.)
0: https://www.elastic.co/docs/api/doc/elasticsearch/operation/...
Probably closer to 2019. Maybe the optionality is a relatively new feature then.
I think graphQL as a byproduct of some serious shenanigans.
"Your GraphQL HTTP server must handle the HTTP POST method for query and mutation operations, and may also accept the GET method for query operations."
Supporting body in the get request was an odd requirement for something I had to code up with another engineer.
And the whole GET/POST difference matters for GraphQL at scale: we saved a truckload of money by switching our main GraphQL gateway requests to GET wherever possible.
Servers can support it but not browsers.
And oftentimes some endpoints simply hit the max URL length limit and need a proper body. I thought we ought to already be using this method. Seems quite fitting for fulfilling GETs with bodies.
Maybe send the body in a close envelope as some software might also write the request body contents to disk or log it.
At this point I’m infamous in my company for complaining about how something should have been done with a QUERY verb but it hasn’t been approved yet.
The cases tend to look like this: - An endpoint was implemented as a GET endpoint, since it’s for getting data, with the search terms in the query parameters. The search term got too long, breaking a critical behavior in production environments. - An endpoint was implemented as a POST endpoint, despite it being an idempotent query for data, since the request body is too large to fit in query parameters. New employees repeatedly come in and are confused why it’s not a GET endpoint, or why it doesn’t modify anything.
A POST could be viewed as creating a "search" which, once given an ID could be retrieved later with a GET.
I know this densest really work with ad-hock and cheap queries but it does for more expensive / report style ones.
Also cases where a GET makes more sense, but there is concern about sensitive data in query parameters getting exposed in logs, so POST is used instead.
You can always configure your HTTP logger to not log query parameters.
From a security perspective it is best to assume everything in a GET query is public, it's not always your server logs that you have to worry about, it could also be logs on the clients system (as an example).
And here I am, using JSON-RPC 1.0 over HTTP for internal APIs, skipping all these debates.
You also miss out on standardized HTTP caching mechanisms since those don't work with POST requests.
We don't want this on our use case so it's fine.
A couple of quick observations and comments after skimming through this (some of these are mentioned or hinted at in the RFC).
With HTTPS used almost everywhere, using this QUERY method (when standardized) could prevent bookmarking specific “GET” URLs if the developers thoughtlessly replace GET everywhere with QUERY.
One of the advantages of GET is the direct visibility, which makes modifications simple and easy for almost anyone (end users, testers, etc.).
The larger question I have is who will choose to adopt it sooner, with web servers, web application frameworks and web browsers in the mix.
The situations where I've wished for GET to be able to have a (typically JSON) body were all in situations where the request isn't "user visible" in the first place. That is: API calls, SPA apps, ajax requests, that sort of thing. Not something people are really supposed to bookmark or call directly.
If today you're doing some JS-fu to make an ajax GET request then you already need to do something to have permalinks (if desired).
Completely worth bringing up and thinking about, but unless I'm missing something I don't think a QUERY verb will change all that much here?
> unless I'm missing something I don't think a QUERY verb will change all that much here?
The semantics are important. GET APIs are expected to be safe, idempotent, and cache-friendly. When you are unable to use GET for technical reasons and move to POST, suddenly none of the infrastructure (like routers, gateways, or generic http libs) can make these assumptions about your API. For example, many tools will not attempt to put retry logic around POST calls, because they cannot be sure that retrying is safe.
Having the QUERY verb allows us to overcome the technical limitations of GET without having to drop the safety expectations.
I like the safety aspect of QUERY. Having CDNs cache based off the semantics of the content might be a hard ask. I wonder if this might lead to a standards based query language being designed and a push for CDNs to support it. Otherwise you probably need to implement your own edge processing of the request and cache handling for any content type you care to handle.
Yes, I understand that. I'm just commenting on the "bookmarkable" aspect here, obviously.
You can just use body with GET. QUERY is redundant.
Just release change to this RFC and adjust GET body semantics. Much easier than introducing a whole new verb and already supported in a lot of software.
> With HTTPS used almost everywhere, using this QUERY method (when standardized) could prevent bookmarking specific “GET” URLs if the developers thoughtlessly replace GET everywhere with QUERY.
You're bothering about non-issues. Bookmarks support GET requests, not any other verb. Like it has always been, if you need to support bookmarks then you implement bookmarkeable URLs to be used with GET requests.
Also, your far-fetched example failed to account for the fact that nowadays POST requests are used to query.
As inefficient as encoding everything into the URI is, I really enjoy being able to bookmark and share specific filter configuration. More than one I've seen some sites with UI so bad, that manually editing the url is the easiest way to get it to do what i want.
Okay, I’m a little confused, the HTTP already supports 8000 octets, and some are having issues because they have too many filters?
Looking at the logs I see that most of the long URI traffic is due to UTM and other tracking related codes, which are mainly a way to work around 3rd party cookie blocks.
I must be missing something, because it sounds like to goal is to have longer URI without the need for encoding URL parameters, but without using POST.
Yes.
Suppose you have one filter but it has a few hundred twenty-character values.
Cough Splunk
Also another case is as a dev you are dealing with guids all day and it can be fast to swap guids around in the browser bar vs. ui steps.
> As inefficient as encoding everything into the URI is, I really enjoy being able to bookmark and share specific filter configuration.
That is perfectly fine. Sites that support path- and query-based filters are already designed specifically to have filters embedded in links, which are GET requests. The QUERY method is something more in line of a GraphQL style of query that isn't held back by the semantics of a POST request. GraphQL didn't invented this API style. If GraphQL-style APIs didn't affected how WebApps implemented links, QUERY methods won't.
Yes! This sounds like a great idea to me. It does have some trade-offs, but I think we would've been better off with this than ever having put queries in the URL in the first place. Rather, if it made enough sense to have some data in the URL itself, it would be better if it could actually be in the path, to distinguish it as a distinct resource. I think there are many reasons why this didn't work out that way but I also think those reasons are mostly historical. I would prefer things like /map/<lat>/<long>/, for example. I don't want to go as far as to say that query parameters were entirely a mistake, but there's nothing they do that couldn't be done otherwise, they just offer a convenient place to delineate unstructured data in a URL that you could then copy around. Sometimes moving that to the path would be awkward (unstructured path elements does exist on the web, but it's weird to do) but often times it would just be better to not have it at all. Don't need UTM codes in my URLs in the first place, and I don't think every single parameter on the page should be in the URL. (If you really wanted to pass someone a saved search full of complex queries, it would be less cumbersome to have a specific URL for saved searches anyhow, in my opinion.)
Obviously query parameters are not going anywhere, but if this achieves enough adoption there is a future down the road where we can stop using POST for any query that wants a payload, without needing to change every single HTTP client in the world. (Many of them can already understand custom methods and treat them basically like posts.)
> I would prefer things like /map/<lat>/<long>/, for example.
PathInfo is a thing you can absolutely use.
Most web application servers have already equipped to be able to easily parse parameters out of the URL path for many years, of course, it's definitely nothing new, it's just that historically, people reached for URL query parameters for this sort of thing. After all, making a request with query parameters is basically built into the browser; you can do it with <form> and anchor links with no JS needed.
Presumably, because of that, many pages will continue to use query parameters for the foreseeable future. I think that's fine, but at least for APIs, the QUERY method could eventually be a very nice thing to have.
Making GET requests have bodies as the norm would also handle this
I might be misunderstanding something, but it seems the issue isn't really about whether GET can technically carry a body. The deeper concern is that HTTP methods have specific meanings, and mixing those signals can causes confusion and it's nice to have this semantic separation.
If you look at the summary table, the only difference between a GET and a QUERY is that the query can have a body. Other than that, they have the exact same characteristics and purpose, so there isn’t really a need to semantically separate them.
> If you look at the summary table, the only difference between a GET and a QUERY is that the query can have a body. Other than that, they have the exact same characteristics and purpose, so there isn’t really a need to semantically separate them.
This is outright false. RFC9110, which clarifies semantics of things like GET requests, is clear on how GET requests should not have request bodies because it both poses security issues and breaks how the web works.
Just because your homemade HTTP API expects a GET request packs a request body, that does not mean any of the servers it hits between your client and your server will. Think about proxies, API gateways, load balancers, firewalls, etc. Some cloud providers outright strip request bodies from requests.
The internet should not break just because someone didn't bothered to learn how HTTP works. The wise course of action is to create a new method with specific semantics that are clear and actionable without breaking the world.
> I think you are confusing what I am saying. I am saying the rest of the semantics are the same, other than the body.
This is fundamentally wrong. The semantics are not the same, regardless of whether there's even a request body or not. The semantics are completely different. One is safe and idempotent, whereas the other is neither safe nor idempotent. The presence of a body doesn't even register as a factor.
> If we are creating a new HTTP spec
Also wrong. It's all about specifying another HTTP verb. HTTP is already specified to support other verbs.
> we could give GET and QUERY be the same because they serve the same semantic purpose.
QUERY is a GET that is designed to pass query parameters in request bodies, which GET explicitly does not support. They are separate operations which just so happen to be both safe and idempotent.
The problem is that they are not enforced. You can already have GET requests that modify state even though they are not supposed to.
What you are actually doing when making a specific kind of request is assuming the actual properties match the documented properties and acting accordingly.
A QUERY seems to be no more than a POST that documents it is idempotent. Furthermore, you should only QUERY a resource that has advertised it is idempotent via the “Accept-Query” header. You might as well name that the “Idempotent-Post” header and then you just issue a POST; exactly the same information and properties were expressed and you do not need a new request type to support it.
HTTP semantics aren’t hard enforced but that only means something if you always control the client, server, and all the middle layers like proxies or CDNs that your traffic flows over.
Your GET request can modify state. But if your request exceeds a browser’s timeout threshold, the browser will retry it. And then you get to spend a few days debugging why a certain notification is always getting sent three times (ask me how I know this)
Similarly, you can put a body on your GET request in curl. But a browser can’t. And if you need to move your server behind cloudflare one day, that body is gonna get dropped.
> A QUERY seems to be no more than a POST that documents it is idempotent.
This is false.
By design QUERY is both safe and idempotent. In the context of HTTP, safe means "read-only", whereas idempotent means that a method does not introduce changes on the server, and thus many requests have the same effect of posting a single request.
The fact that the semantics of an operation is deemed safe has far-reaching implications in the design of any participant of a HTTP request, including firewalls, load balancers, proxies.
> You might as well name that the “Idempotent-Post” header and then you just issue a POST;
This is outright wrong, and completely ignores the semantics of a POST request. POST requests by design are neither safe not idempotent. You do not change that with random request headers.
> Outright wrong. You are allowed to handle POST requests in a safe and idempotent way.
You clearly have no idea about what you are discussing. The definition of HTTP verb semantics clearly defines the concept of safe and idempotent methods. You should seriously learn about the concept before commenting on discussions on semantics. If that's too much work, RFC 9110 clearly and unambiguously states that only the GET, HEAD, OPTIONS, and TRACE methods are defined to be safe. Not POST.
It's completely irrelevant if you somehow implemented a POST method that neither changes the state of the server nor returns the same response whether you invoke it once or many times. All participants in a HTTP request adhere to HTTP's semantics, and thus POST requests are treated as unsafe and non-idempotent by all participants. That affects things like caching, firewalls, even security scanners. The HTTP specs determine how all participants handle requests, not just the weekend warrior stuff someone chose to write in a weekend.
I'm confused - wouldn't idempotent POST be PUT? Isn't the proposed QUERY for fetching semantics?
Whatever the original intent was, POST definitely does not return a new record consistently in most actual APIs. It's frequently used for actions that don't conceptually create anything at all.
No, I was referencing the example in the article in literally the very first section showing and explaining how POST endpoints are used for fetching data when GET endpoints are too limited. This is literally their motivating impetus for the QUERY request type.
When considered abstractly, POST is just a request body and a response body. This is obviously powerful enough to define any behavior you want; it is just a channel flowing a nearly arbitrary amount of opaque data between the client and server.
However, this kind of sucks because it does not define or constrain the behavior of the client or the server. QUERY says that the server is intended to interpret the request body as fetch parameters and return a response body as the fetched data, and further guarantee that the fetch is safe/idempotent. This is very useful.
My disagreement is that there is no good reason for the client request format to care. You should “POST” to a “QUERY” endpoint. The fact that this endpoint guarantees QUERY behavior is just part of the documented server interface in the same way that certain endpoints may not support PUT. This is a server constraint, not a client constraint so should not change the client transport format.
Requiring a new Client request type to agree with a new Server endpoint type is just unnecessary and mixes up server versus client responsibility and interface design.
PUT is the idempotent one. POST typically performs an action; PUT just creates-or-updates.
The existing mechanism to get QUERY semantics is a POST that encodes the “fetch parameters” in the body and the response contains the fetched values. You then out-of-band document that this specific use of a fetching POST is idempotent.
This is literally expressed in the document in section 1: Introduction. They just want to take that POST request and replace the word POST with QUERY which also means the server is intended to assure the request is idempotent instead of needing that documented out-of-band.
> For some reason the RFC focuses on idempotency,
It focuses on a bit more on safety, which is why every mention of it the proposed method having the "idempotent" property is immediately preceded (in most cases in the same sentence) by description of it having the "safe" property.
Does “safe” here mean just “non-mutating”?
It would be pretty impossible to actually ‘enforce’ that GETs don’t modify state. I am not sure if I would call the lack of enforcement a problem when it is more a simple fact about distributed systems; no specification can enforce what a service does outside of the what is returned in a response.
> There is no reason to syntactically distinguish what is semantically non-distinguishable.
The point is to have a standard, so you can more easily learn what an API is doing instead of having to start from scratch every time.
GET is a keep things simple stupid approach to caching. The URL is the cache key plus any headers touched by the vary header. Adding the requirement to vary on the body and understand the body content semantics brings in a whole lot of complexity that GET avoids.
That ship sailed decades ago. Too much software and middleware expects GET to not have a body and who knows how itll break when you start sending one. Obviously you can do it today and it might work and then randomly break when the code between client and server changes.
Adding a new http method is the only way to support something like this safely. If something in between doesn't know what to do with QUERY it can just respond with a 501.
Fun fact - GET and HEAD are the only required methods one needs to implement to be an http server. It is a pretty low bar :)
you're right
I suspect the challenge would be all the middleware that assumes that get never had a body.
> Making GET requests have bodies as the norm would also handle this
The RFC is pretty clear that no participant in a HTTP request is expected to even allow a GET request through. RFC 9110 even states quite clearly that it's even a potential request smuggling attack. Some major cloud providers provide API Gateway implementations that outright strip request bodies from GET requests.
I think you are missing the whole point of proposing a new HTTP verb. Changing the semantics of a GET request is not an option because of both the security risks it presents and the fact that the infrastructure of the whole internet either is designed to reject these requests or outright breaks. See how GET requests are cached and how cache implementations don't discriminate GET requests based on it's request body.
or get requests with query params already handles this in majority of the cases, unless the query size is too big (which ideally should not be the case since in the end it is a get request)
Yeah, it works already, this RFC makes no sense.
Does anyone know what blocks something like this being accepted? I’ve had my eye on this for ages and have had to work around its lack multiple times, so just curious what the hold up could be.
You can check the mailing list for the current discussion.
https://lists.w3.org/Archives/Public/ietf-http-wg/
There's also some tracking on GitHub.
https://github.com/httpwg/http-extensions/issues?q=label%3Aq...
It’s rare that I have a project that justifies the full DDD treatment, but one of the great ideas from it that stuck with me was command/query separation, where you separate out queries, which can be mangled agglomerations of objects for reporting and lists, from commands, which drive your business logic.
I love the idea of a separate verb. It always felt like get is just not quite enough.
CQRS
Interesting that instead of just allowing GET with body the proposal went with a new HTTP method. I wonder if this would delay the support by proxies and other middle boxes. It seems supporting body would be easier than a new method.
What’s wrong with POST’ing a report?
POST to /reports with the query parameters in the body. Respond with bookmarkable, cacheable /reports/id and GET /reports/id
And that’s only necessary for huge, complex queries. If filtering some resources doesn’t fit into the URL you might want to rethink what you’re doing.
The convention for internal "Query" routes in my company is just a Post with a path starting with "/queries" This is taken care of in eg. our retry middleware.
Not as good as a standardized idempotent Method, but good enough for the time being till they finally approve this as RFC
For the experienced devs. May I ask why would one use POST for everything?
I encountered a codebase with only POST for all operations, given my lack of knowledge in this area, I am not sure why one would choose POST only over the standard set of GET, PUT, POST, DELETE, etc.
I prefer POST for everything. The main reason why is because HTTP verbs don't match cleanly to every operation. And it leads to a lot of bike shedding around the exceptions. POST for everything, on the other hand, forces you to put the "method" in the request outside of HTTP semantics, which allows you to "just use" whatever verb makes sense rather than trying to map it to the limited ones available.
GET: I want to see stuff.
POST: I want to change stuff.
I don't know how this style cannot match cleanly any architecture.
It's not supposed to be a map to CRUD, it's a bunch of building blocks for manipulating state over a network.
PATCH: I want to change stuff.
PATCH: I want to change stuff in a predictable way.
--
PUT: I want to replace stuff.
DELETE: I don't want anyone to GET that stuff anymore.
HEAD: I want to peak at how stuff is shown.
OPTIONS: I want to know what I can do with stuff.
--
COPY: I want to copy stuff (WebDav)
MOVE: I want to move stuff (WebDav)
MKCOL: I want a new sublevel of stuff (WebDav)
PROPFIND: I want to list stuff (WebDav)
PROPPATCH: I want to mass change stuff (WebDav)
LOCK: I want to control who METHODs stuff.
UNLOCK: I want to remove control over who METHODs stuff.
--
All of those are actually optional. It is okay to use POST[0]. GET and POST with proper hypermedia (media types and links) is all 99% of apps need.
[0]: https://roy.gbiv.com/untangled/2009/it-is-okay-to-use-post
What if the stuff you want to see can't be encoded in a URL?
Hmm... sort of like an intermediate page?
That would explain a some of the design decisions. I had to do work on a old codebase and am studying it.
Thank you and the others too for the input.
Because with POST you have a RPC (remote procedure call) with arbitrary semantics and HTTPS is just a convenient transport.
That's also why I only use a couple of status codes: Ok, Created, NoContent, BadRequest, Forbidden, Unauthorized an InternalServerError (the latter two generated automatically by the framework).
GET, PUT, DELTE, etc. seem to be tailored towards entities, but as soon as the endpoint is not an "entity", the semantics get vague and break down.
Consistency, simplicity, RPC semantics.
The default for GraphQL queries is POST so maybe they were using that.
It was safer in some sense before TLS. No data in URL.
If you encounter a shop that uses POST for everything then they are probably a shop that doesn't know that verbs other than GET and POST exist.
... and they don't use GET everywhere because one time Google scraped that endpoint and dropped the production database.
I suppose this is the kind of thing that would be handled by a separate RFC but I hope that browsers will be allowed to send QUERY requests via HTML <form> elements since traditionally they can only send GET and POST.
I anticipate this will be used by UI frameworks to transmit a very long list of item ids selected by the user using check boxes. Which will cause suffering to the backend devs dealing with relational databases
What do you mean by that? What's wrong with a simple
WHERE id IN (id1, id2, id3, ...);it's very slow and resource consuming
How does one share the search results with the url to the page with this query method?
Just add a body to GET.
Obviously doesn’t work with all systems, but QUERY works with even fewer.
First impression was "umm... I don't even use SEARCH yet." Then realize this is actually SEARCH method but renamed and more generalized.
[dead]
0.1% of people will implement this into their code.
Waste of time.
In the first ten years? Maybe. After that, it might become mainstream.
We already have POST, PUT, and PATCH that do the exact same thing. Why not have another version of GET that looks the same as POST and is subject to personal interpretation.
FYI: QUERY is for GET requests where the query string make the URL too long. It does this by sending a body like POST.
In the past, POST meant you were sending a body, and GET meant you received a body. And the people got religious about a pseudoacronym called REST.
Apart from the sectarian conflicts about what REST means, having a HTTP method that proxies can cache like a GET but allows bodies is pretty useful from a purely practical standpoint. You can do this with POST, but it requires proxy-specific configuration.
The point of the HTTP verbs is to communicate expected behavior. While a server could treat POST, PUT, and PATCH the same, the point of having the verbs at all is to give a standard way to signal clients what is going to happen. While a server can ignore the expectation, it doesn’t mean the expectation isn’t valuable; it allows conforming implementers to communicate what is happening using standard language.
> please use the IETF Datatracker URL.
On my phone, your Datatracker link results in an unreadable mess of a page due to the hard-coded line breaks in the plaintext rendition of the RFC text (making it unreadable in portrait mode) and the huge sticky page nav (causing the content viewport to shrink vertically to almost zero in landscape mode). The HTML page behind OP's link reads just fine.
> The best way to view an RFC, IMHO, is to use the "htmlized" format
I don't see any choices of format such as HTML behind your link. There's a sticky nav, then a couple of pages of metadata, followed by a plaintext rendering of the RFC. What am I missing?
When I open the link there is a table of information before the main RFC text. One row is titled ‘formats’ in bold and has a ‘htmlized’ link in it. Presumably that is what you were missing due to some understandable banner blindness.
In the top section where there’s authors etc, there’s a format list. I didn’t see it the first time.
It reads decently in landscape mode, and i’m on a small screen (iPhone se 3rd gen).
It shows me only seven lines of text at a time [0], too few for me to read comfortably, let alone make sense of e.g. diagrams. Firefox on Librem 5.
[0]: https://0x0.st/KJZ_.png
From the Datatracker, I can see that it was called SEARCH until draft-2 (Nov 2021), and then changed to QUERY.
Also, the previous SEARCH method was proposed in Apr 2015 (!!), but nobody took it seriously, and it never gained traction back then. A lot of software was developed/updated during the last decade, and a lot of opportunities were missed. Even if the QUERY method is turned into a formal RFC right now, expect 10+ years for everyone to adopt it, without running into HTTP-405 or 501's.
It just takes some significant piece of server software to start accepting it, RFC or not. "Write code, not laws", or however was that formulated.
See the history of the PATCH method, and of the whole WebDAV thing.
To quickly retrieve an RFC I use a script named "rfc". I save RFCs as text files not HTML so I prefer the .txt version
yy025 makes custom HTTP, more flexible than curl6f6b is TLS forward proxy
yy045 removes chunked encoding
less is more(1)
For drafts I use a metasearch script
+1 for non-paginated results
yy084 makes SQL from SERP