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.
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.
> 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.
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.
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/...
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 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.
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.
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.
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.
> 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.
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.
You can just use body with GET. QUERY is redundant.
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.
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.
> 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.
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.
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! 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.
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.
> 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.
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.
I'm confused - wouldn't idempotent POST be PUT? Isn't the proposed QUERY for fetching semantics?
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.
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.
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.
That is exactly my point. There is no reason to syntactically distinguish what is semantically non-distinguishable.
The interpretation of a request is up to the server. There is no reason for the client to syntactically distinguish that the request body is for a POST vs QUERY; the request parameters and response have the same shape with the same serialization format.
However, on the other side, a server does control interpretation, so it is responsible for documenting and enforcing how it will interpret. QUERY semantics vs generic POST semantics is a receive/server-side decision and thus should not be a syntactic element of client requests, merely a server description of endpoint semantics (“QUERY endpoint” meaning shorthand for POST endpoint with query semantics).
edit: Thinking about it some more, there is one possible semantic difference which is that a transparent caching layer could use a syntactically different POST (i.e. QUERY) to know it should be allowed to cache the request-response. I do not know enough about caching layers to know how exactly they make fill/eviction choices to know if that is important.
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
> 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.
Yeah, it works already, this RFC makes no sense.
I suspect the challenge would be all the middleware that assumes that get never had a 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)
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
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.
What if the stuff you want to see can't be encoded in a URL?
I'm assuming the case here is lots of query params. Stuff like `?foo=bar&lorem=ipsum...`.
Most likely, you would benefit from making a cirurgical mini-resource on the server.
Introduce `/report/{id}`, and make it into a POST.
The user POSTs to `/report`, and the answer is 201 (Created) or 202 (Accepted), with a `Location: /report/123` (generated short id). The thing you changed on the server, is that now that long list have a short id. Just that.
Then, the user `GET /report/123` (auto redirect). It all happens within the same socket (keep-alive) and it has almost zero overhead (one refresh without this probably has thousands of times more overhead than the redirect).
By doing that, it seems that you are wasting stuff, but you're not.
Now the user doesn't have to transfer huge amounts of query data when GETing the results again, cache layers will have an easier time, and you can even use that mini-resource as a shortcut to solve things like racing conditions (two users doing the same humongous query at the same time).
Realistically, unless you're some query-by-image type of thing (trying to search images that match an existing one), you'll never actually have to face URL limits. If you are one of those cases, then you probably already have other architectural constraints that would justify introducing the extra intermediate resource.
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
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.
It was safer in some sense before TLS. No data in URL.
Consistency, simplicity, RPC semantics.
The default for GraphQL queries is POST so maybe they were using that.
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.
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.
How does one share the search results with the url to the page with this query method?
First impression was "umm... I don't even use SEARCH yet." Then realize this is actually SEARCH method but renamed and more generalized.
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, ...);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?
It reads decently in landscape mode, and i’m on a small screen (iPhone se 3rd gen).
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.