The HTTP Query Method

[zzq1015]

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.

[Hackbraten]

> 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?

[zzq1015]

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.

[1vuio0pswjnm7]

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

   echo https://www.ietf.org/rfc/rfc$1.txt|yy025|nc -vv 6f6b 80|yy045|less

yy025 makes custom HTTP, more flexible than curl

6f6b is TLS forward proxy

yy045 removes chunked encoding

less is more(1)

For drafts I use a metasearch script

+1 for non-paginated results

   ;;64) #``````````` datatracker
   shift
   x=$(echo "$x"|sed 's/ /+/g;s/++/+/g')
   echo "https://datatracker.ietf.org/doc/search?name=$x&activedrafts=on&olddrafts=on"|yy025|(yy084 64 "$x";nc -vv 6f6b 80)
   exit

yy084 makes SQL from SERP

[gridlocdev]

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.

[chrisandchris]

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.

[resonious]

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!

[carlosneves]

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.

[ahoka]

Maybe send the body in a close envelope as some software might also write the request body contents to disk or log it.

[gbear605]

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.

[tempest_]

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.

[thayne]

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.

[JodieBenitez]

And here I am, using JSON-RPC 1.0 over HTTP for internal APIs, skipping all these debates.

[newscracker]

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.

[arp242]

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?

[locknitpicker]

> 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.

[leloctai]

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.

[itopaloglu83]

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.

[nrhrjrjrjtntbt]

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.

[locknitpicker]

> 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.

[jchw]

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.)

[stephenr]

> I would prefer things like /map/<lat>/<long>/, for example.

PathInfo is a thing you can absolutely use.

[chronicler]

Making GET requests have bodies as the norm would also handle this

[platzhirsch]

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.

[badbotty]

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.

[bhawks]

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 :)

[vlovich123]

I suspect the challenge would be all the middleware that assumes that get never had a body.

[locknitpicker]

> 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.

[ashu1461]

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)

[vbezhenar]

Yeah, it works already, this RFC makes no sense.

[andyferris]

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.

[8organicbits]

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...

[clickety_clack]

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.

[tough]

CQRS

[fpoling]

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.

[fogzen]

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.

[onfir3]

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

[8cvor6j844qw_d6]

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.

[nhumrich]

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.

[zvrba]

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.

[LudwigNagasena]

Consistency, simplicity, RPC semantics.

[RedShift1]

The default for GraphQL queries is POST so maybe they were using that.

[iberator]

It was safer in some sense before TLS. No data in URL.

[julianlam]

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.

[tlhunter]

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.

[slim]

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

[culi]

What do you mean by that? What's wrong with a simple

  WHERE id IN (id1, id2, id3, ...);

[llIIllIIllIIl]

How does one share the search results with the url to the page with this query method?

[paulddraper]

Just add a body to GET.

Obviously doesn’t work with all systems, but QUERY works with even fewer.

[hamasho]

First impression was "umm... I don't even use SEARCH yet." Then realize this is actually SEARCH method but renamed and more generalized.

[gethly]

0.1% of people will implement this into their code.

Waste of time.

[aiven]

In the first ten years? Maybe. After that, it might become mainstream.

[fijiaarone]

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.

[johncolanduoni]

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.

[cortesoft]

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.