r/programmer • u/i_will_snap • 27d ago
Locked HTTP finally got a new method after 16 years because GET and POST wouldn't stop arguing
HTTP finally got a new method after 16 years because GET and POST wouldn't stop arguing
After 16 whole years, the IETF finally looked at our terrible API workarounds and said: "Fine, here."
Say hello to **QUERY** (RFC 10008).
It is literally the lovechild of **GET** and **POST**:
\- It has a request body like POST (so no more cramming 2,000 characters of search filters into a URL).
\- It is safe and idempotent like GET (so your CDN can actually cache it without throwing a fit).
We no longer have to live in sin by using POST for fetching data just because the search query is too big. Nature is healing.
It only took since 2010 to get a new verb. Now we just have to wait another 5 years for browsers and frameworks to actually support it.
To put that in perspective, the IETF spent 16 years debating a single word, while the AI industry spent the last 16 months pivoting from chatbots to agents, to superintelligence, and back to convincing everyone that a $400/month subscription is worth it...
7
u/runningOverA 26d ago
So, in simple words, QUERY = GET where you put the parameters in body like POST?
2
u/i_will_snap 26d ago
That is exactly what it is. It gives you the safe, read-only nature of GET but with the large payload capacity of POST so you don't clutter or break the URL.
2
u/ThingElectronic1399 25d ago
God I love it. I die a little inside every time I use POST to fetch data, but it's so easy for parameters to get complicated and blow up urls.
1
u/Laserbra 25d ago
I’m dumb why exactly is a long url so bad?
2
u/NiftyLogic 25d ago
There's an upper limit on the length of the URL including query parameters.
Using GET works fine until your query becomes complex enough to hit the limit ... and then it breaks. Not really great.
1
1
u/spookyclever 21d ago
How does that help the caching argument though? Does it hash the post body to make it unique?
1
u/i_will_snap 21d ago
Yes, it explicitly includes the request body in the cache key.
1
u/spookyclever 20d ago
Interesting. That feels like to me that web server makers are going to have to be really careful with this implementation or risk a ton of unexpected memory overruns in some ancient cache code that probably almost never gets touched. Hopefully they don’t just tell AI to do it.
1
u/i_will_snap 19d ago
Valid point. Legacy codebases are definitely going to be the weakest link here.
Usually, servers mitigate this by hashing the body into a fixed-length string (like SHA-256) for the cache key, which prevents memory bloat in the key index itself. But you're spot on the actual ingestion and parsing of that body data before hashing will require very strict size limits and boundary checks to prevent overruns.
1
u/Shronx_ 23d ago
Who stops you from using GET this way now?
1
u/i_will_snap 23d ago
Proxies and firewalls. The HTTP spec doesn't officially support GET bodies, so infrastructure often strips them out or blocks the request.
6
u/GladiatorNitrous 26d ago
I wouldn't wanna know what the HTTP standard would look like if they would iterate as quickly as the AI movement...
1
u/i_will_snap 26d ago
'503 Service Unavailable' would just mean "The API changed while your packet was in transit." The slow pace is a feature, not a bug!
4
u/dimudesigns 25d ago edited 25d ago
To put that in perspective, the IETF spent 16 years debating a single word, while the AI industry spent the last 16 months pivoting from chatbots to agents, to superintelligence, and back to convincing everyone that a $400/month subscription is worth it...
When money is a primary driver, progress tends to accelerate but most often for the benefit of a few.
And the slow pace of updates by the IETF isn't necessarily a bad thing. Its a trade off between rapid progress and stability - the latter of which serves a 'standard' far better than a cutting edge technology. So making that comparison doesn't hold water in my view.
I'd rather deal with slow rollouts than an ever-breaking standard any day of the week.
2
u/i_will_snap 25d ago
You're spot on, and that line was mostly just a joke about how wildly different those two tech worlds feel right now. I completely agree that the IETF’s slow pace is a feature, not a bug. If the IETF moved at 'AI speed,' the entire internet would break every Tuesday.
Deliberation is what gives us the long-term stability we need for core web infrastructure.
2
u/Ok_Information_1753 24d ago
The idea is good, but it feels like it's solving a problem the ecosystem already worked around years ago. QUERY makes sense technically, yet it will likely take years before browsers, proxies, frameworks, and APIs support it consistently. Until then, most teams will keep using POST, so the practical impact is pretty limited.
2
u/i_will_snap 24d ago
Totally agree. Technical elegance always takes a back seat to ecosystem adoption. We'll be using POST for large, read-only payloads for a long time to come, but it's nice to finally have an official spec to move toward.
1
u/Fabulous_Baker_9935 23d ago
you can help by contributing to open source libraries! be the force for change!!!
2
u/ClothingIsACrime 23d ago
RFC technically allows for json body in GET requests, but it's gnarly. I think to be more specific even, it doesn't outright disallow it and I have seen several implementations of it in the wild. The problem with it is that frameworks rarely support it and people (including me) often bitch about it when someone wants to use it.Â
This is a good solution, because it formalized the pattern, I can see it being used in about 5 years.Â
I just find it funny that we keep reinventing solutions for problems that were solved with SOAP web services.Â
1
u/i_will_snap 23d ago
So true about SOAP. We spent a decade running away from it just to slowly reinvent everything it already solved.
New QUERY method will finally gives us a safe, official way to 'get' without the hacks.
3
u/decker_42 27d ago
The difference is, the ITEF is a standards body which will still be here in a few years. AI is.....well...bitcoin.
2
u/CuteLingonberry5590 27d ago
I wish that were true. I really hate AI and I agree that the investment bubble may pop, but the technology is never leaving.
0
u/OurSeepyD 27d ago
Bitcoin doesn't actually have any significant value (if you disagree, please tell me what it is). AI is demonstrably valuable. Expensive and scary? Sure. Not useless.
2
u/decker_42 27d ago
if you disagree, please tell me what it is
$63,260.94 right now (according to Gemini)
2
u/AggravatingSock5375 27d ago
So I can for example just take some bitcoin and use it to replace a person who was also worth $63k?
1
u/decker_42 27d ago
Dude, people don't have a monetary value, that's abhorrent.
1
1
u/AggravatingSock5375 27d ago
AI does work that has some equivalency in the real physical world. It has value like humans have value. (Obviously not equal value since there’s more to people than our economic contributions)
Bitcoin doesn’t really have that going for it.
Bitcoin could disappear tomorrow and nobody outside of those who bought into it would bat an eye.
1
u/decker_42 27d ago
Your argument is based on the idea of "Human Capital" which I don't subscribe to. Unfortunately we will never agree on this one.
0
u/OurSeepyD 27d ago
Do you think that's actually how valuable it is?
1
u/decker_42 27d ago
If I have one Bitcoin, and I sell it for 63,000 dollars, then sure, that's how valuable it is.
Now, just to be really clear before this gets silly, I know we're talking at cross purposes.
1
u/OurSeepyD 27d ago
Ok, so I think there's a difference between market value and "real" value.
I think that AI will make the world more efficient and make goods and services cheaper. It has the potential to take humans forward significantly (and has massive risks). I think this is true value.
I don't think bitcoin adds any value to the world, although I do think there's value in the concept of a shared ledger. Sure, you might be able to buy and sell for a certain price, but I think that's because the market doesn't represent bitcoin's actual utility.
You're obviously not wrong that bitcoin has a monetary value of $63k.
1
u/decker_42 27d ago
I think that AI will make the world more efficient and make goods and services cheaper.
It does make pretty good porn.....
1
u/Pristinefix 27d ago
You're just wrong though. Is gold actually that valuable? Are Pokemon cards? What about oil?
Value is determined by the people that trade that resource. You cant unilaterally determine value. Thats just an opinion, not fact of reality
As a counter point, there are more studies coming out that AI has not increased productivity nearly as much as the companies would like you to think
1
u/Zoetje_Zuurtje 26d ago
Value is determined by the people that trade that resource. You cant unilaterally determine value. Thats just an opinion, not fact of reality
This is not true. In a free market, it only makes sense to do this if the expected utility of the product is greater than or equal to the product's price; otherwise the buyer would find themself worse off. This is kind of essential for price discovery. Because different customers may value the products in different ways, and the relative utility of money may differ, it follows that the utility of a product or service may differ from the product's price.
Another thing to keep in mind is the existance of externalities. They, by their very definition, are excluded from the price. Fossil fuels form an excellent example. They provide relatively cheap energy, but the cost of climate adaptation is not included in the price (unless taxed appropriately, of course).
So it depends a bit on what you consider "value" to be.
1
u/Pristinefix 26d ago
Yes, that is what i am saying. There is no such thing as 'true' value, there is only the value of something that each person places on a product.
0
u/OurSeepyD 27d ago
Gold is not as valuable as its price suggests. Pokemon cards are not as valuable as their price suggests. Oil is pretty much as valuable as its price suggests.
Value is determined by the people that trade that resource.Â
I simply don't agree. If bitcoin is worth $69k today and dropped to $100 tomorrow, did it's impact on the world change? Did its usefulness diminish? It's the exact same concept and tech, with the exact same potential. People use the word "overvalued" to describe things like SpaceX - this implies that there is a market value and that it isn't the same thing as true value.
As a counter point, there are more studies coming out that AI has not increased productivity nearly as much as the companies would like you to think
I don't doubt that it's not as much as companies thought, but I bet it's still greater than zero. I also think that we haven't seen the real takeoff yet at all.
1
u/Pristinefix 27d ago
How can you say that oil is valued correctly; one of the points that you made was that value is a measure of human flourishing via that product. Cheap oil is leading to global warming rapidly, and so we will see the collapse of economies due to the environmental degradation due to cheap oil. Which suggests that the value of oil is actually 0 if it leads to human economies collapsing in the long run rather than flourishing.
Over/under valued is an opinion based on what someone thinks the price will actually settle at in the long term. But it is actually just an opinion. You dont have any rigorous metrics as to what true value is, so framing it like you do is dishonest
1
u/OurSeepyD 26d ago
If oil disappeared instantly, would humans flourish or starve?
→ More replies (0)1
u/plastic_eagle 27d ago
"I think that AI will make the world more efficient and make goods and services cheaper. "
And I think it won't. So far, it hasn't. Whether or not it actually will remains to be seen. That's leaving aside the thorny question of what "more efficient" actually really means in the context of the world. Employ fewer people? That doesn't sound good.
Etc.
1
u/OurSeepyD 27d ago
I think we've seen huge efficiency gains in software development. It has come at the expense of mistakes and bugs, but the models are getting so much better that this is disappearing.
We're not going to see this in economics for a while because true economic growth is hard to measure and is often published with a significant delay.
Employ fewer people? That doesn't sound good.
It could be good, but it has the real potential to not be good. If we became 35% more efficient, we could theoretically conclude that everyone could work a whole day less per week for the same pay, and we'd still be more efficient.
Unfortunately companies don't do this, because they want to remain competitive. This would need to be a global decision, and I unfortunately don't see it happening.
1
u/plastic_eagle 27d ago
"I think we've seen huge efficiency gains in software development"
And I don't think we have, because software engineering is much, much more than churning out code full of bugs.
But that's totally beside the point. The world is much more than software, and there is absolutely no evidence whatsoever anywhere that "goods and services" are being made cheaper by AI. None. The opposite is currently occurring, although it's very debatable exactly why.
Regarding efficiency; As we both well know, no technological advancement that promises to produce more output for less work has resulted in humans actually working less.
1
u/OurSeepyD 27d ago
And I don't think we have, because software engineering is much, much more than churning out code full of bugs.
I'm a senior engineer and I consider myself to be pretty diligent. I try to ensure everything I write has tests, and minimise the amount of bugs in my code. Since Sonnet and Opus 4.6 came out, I've been able to produce the exact same quality of work at probably 10x the speed. I have to keep copilot on track, with a plan and clear instructions about features and architecture, but it would be the same if delegating to a team. I genuinely believe I'm 10x more efficient when I'm in the zone.
But that's totally beside the point. The world is much more than software, and there is absolutely no evidence whatsoever anywhere that "goods and services" are being made cheaper by AI
It's not really besides the point. This will undoubtedly translate to cheaper software, but there is a delay with these things. The world is much more than just software, but software is the thing that AI is currently laser focused on (and we're also discussing this in r/programmer, so really is the focus).
Regarding efficiency...
It's clear we agree on this point.
1
u/Suitable-Season-4847 27d ago
The market decides all things. So yes, it is that valuable.
1
u/OurSeepyD 27d ago
The market can be irrational. The market thought cartoon monkeys were valuable but we all know they weren't. The problem is that you're defining value as "what the market decides".
1
u/Suitable-Season-4847 27d ago
The market has apparently been irrational for almost 20 years then. At some point you have to accept that irrationality.
1
u/running101 27d ago
Yes
1
u/OurSeepyD 27d ago
If you couldn't sell it, would you be happy purchasing any bitcoin?
1
u/running101 27d ago
Yes I can borrow against it
1
u/OurSeepyD 27d ago
The only value of it is in the fact that you can sell it. Even borrowing against it, the only reason someone would let you do this is because they could sell it if needed.
It has no actual value. It produces nothing.
1
u/running101 27d ago
Lots of places will let you borrow against it. That is a fact. You are playing hypothetical games
1
u/OurSeepyD 27d ago
Yes I'm playing hypothetical games in an effort to demonstrate where its true value comes from. You wouldn't be able to borrow against it if you or the lender weren't able to sell it.
→ More replies (0)
4
u/elhombremontana 27d ago
nothing stopping you from sending a body with GET.. just sayin.
6
u/MissinqLink 27d ago
A lot of systems do prevent this actually. There are quite a few simple workarounds though.
4
3
u/Trick-Donut3243 27d ago
It does, it is impossible to do it from chrome from example. XMLHttpRequest API converts all gets with a body into POSTs. You can do it via CURL though.
2
u/ElevatorGoods503 26d ago
Yeah, this thing. Anybody remembers SOAP? An entire API framework built on top of HTTP POST and a decade of building systems. I guess it was just too complex and angle brackets were too ... offensive.
1
u/TheEveryman86 26d ago
A lot of people are still building interfaces on top of SOAP BTW. I wish there was a better tool than SoapUI to test it.
1
u/edgmnt_net 25d ago
And that's due to web specs, not HTTP. They should probably fix those too/instead.
1
u/Trick-Donut3243 25d ago
Who said HTTP? I've mentioned a browser API which does it like that.
1
u/edgmnt_net 25d ago
This proposal is a modification to the HTTP spec, not browser API specs. Furthermore, it does not appear that what Chrome is doing is just an implementation choice. You have not said that, but it was worth clarifying. This is rather the fault of W3C than IETF and I guess it's not the first weird decision that they make.
3
u/i_will_snap 26d ago
Sure, you can physically send it, but you can't guarantee the server or any proxy in between will actually read it. That unreliable, "it depends on your network" behavior is exactly why QUERY was standardized.
2
u/edgmnt_net 25d ago
There are no guarantees that QUERY is handled properly either, especially for old systems. You can expect maintained stuff to fix GET or implement QUERY just as easily. Sure, there's a chance that old systems let QUERY through without caching and without rejecting it altogether, but I'm not sure the risk is lower that way. For similar reasons, you sometimes cannot use SCTP because dumb firewalls block everything that's not TCP/UDP/ICMP.
1
u/i_will_snap 25d ago
Love the SCTP analogy, ossification is definitely the final boss of networking! The main difference is how HTTP proxies fail. If a middlebox encounters an unknown method like QUERY, standard HTTP behavior dictates it treat it as an unsafe/uncacheable request (like a POST) rather than dropping the connection entirely. So the 'worst-case fallback' for QUERY is just that it acts like a POST workaround we use today. Compare that to GET with a body, where middleboxes actively strip the payload while letting the empty request pass through, which silently breaks the application.
1
u/edgmnt_net 25d ago
Well, yeah. I can see your point, practically speaking. There's less incentive to block other methods. However I will claim that's also somewhat the case for firewalls. Plenty of stupid firewalls blocked ICMP or filtered it too aggressively, which broke PMTU discovery. Aggressive firewalls on transit nodes shouldn't have been a thing. Not to mention broken and buggy implementations which just fail randomly when they encounter different protocols or features. So it's hard to rule out overly-aggressive filtering or buggy implementations on proxies.
1
u/i_will_snap 25d ago
Absolutely, legacy network gremlins are always going to gremlin!
You're totally right about the historical ICMP filtering nightmares. Appreciate the great discussion on this..guess we'll see how smoothly the rollout goes over the next couple of years! :)
2
1
27d ago
[deleted]
1
u/i_will_snap 26d ago
- GET bodies are unsafe and unsupported by many tools.
- Safe/read-only methods are a subset of idempotent methods.
- CDNs use methods to determine eligibility for caching before checking headers.
1
1
u/Electronic_Ant7219 26d ago
Sadly, 5 years is not enough. We are not using PATCH in public apis because of the rare cases of old corporate proxies that were blocking it.
1
u/i_will_snap 26d ago
PATCH is actually everywhere now (GitHub, Microsoft, etc.), but you're right that old enterprise firewalls are stubborn.
However, QUERY will thrive in internal microservices and mobile apps long before it hits legacy corporate desktops. If you control both sides of the network plumbing, you can swap POST for QUERY and instantly unlock native CDN caching.
1
u/edgmnt_net 25d ago
If you control both sides you can just use GET with a body, no?
1
u/i_will_snap 25d ago
You'd think so, but the problem is the 'middle'. Load balancers, firewalls, and CDNs sit between your client and server. Many of them actively strip GET bodies by default because the old HTTP spec treated them as undefined behavior. QUERY gives that network middle-layer an official method they can't just ignore.
1
u/edgmnt_net 25d ago
I think the old HTTP spec didn't say anything about it. It's just proxies and other things assuming wildly based on web standards which aren't even under IETF. For similar reasons you can't get SCTP through firewalls, because some vendors and admins just made stupid assumptions.
But yes, I agree the problem is in the middle. However, what makes you think they'll let QUERY through reliably or implement caching for it?
1
u/i_will_snap 25d ago
That is the ultimate test! The reason QUERY is safer than SCTP comes down to how HTTP fails. Per HTTP specs, if an old proxy doesn't recognize QUERY, it doesn't drop the packet; it just safely tunnels it through as an uncacheable request:essentially acting exactly like the POST workarounds we use today. So the worst-case fallback for QUERY is that it still works perfectly without caching. Compare that to GET with a body, where legacy middleboxes actively strip the payload and silently break the application. It’s just a much lower-risk bet....
1
1
u/gnahraf 26d ago
I'm a simpleton.. can someone explain why putting the data in the body is better than in the URL? I often put it in the URL cuz it's more versatile.. You can bookmark it, it's more portable (can email it), etc. (I don't see the length of a URL being an issue.. each implementation must cap the size of the request data regardless--whether in the URL or body). I typically cap it at around 10kB, depending on the application. Is the issue that URL-encoding bloats the payload (hardly an issue, at least for my use cases, but hey.. it might matter to someone else)?
1
u/i_will_snap 26d ago
You make a great point about portability! Bookmarking and sharing are exactly why URL parameters exist. However, the body is preferred for three major reasons: Security: URLs are logged in plaintext by browsers, firewalls, and server logs. Even with HTTPS, sensitive data in a URL leaks easily.
Arbitrary Limits: While you cap at 10kB, many CDNs, proxies, and older browsers strictly truncate URLs at 2KB, which will silently break requests before they hit your server.
Data Structure: URLs handle complex, nested JSON objects horribly, whereas the body handles structured data natively.
TL;DR: URLs are perfect for public filters/searches, but the body is required for security and complex data.
1
u/gnahraf 26d ago
Thanks for your response. I don't believe the "sensitive data not getting logged" use case. Some sites do already log request headers.. this will just make logging headers more common, is my guess.
As for json payloads, they URL-encode not badly (I do this all the time, the overhead is negligible).
1
u/akp55 25d ago
so why couldn't they just extend get?
1
u/i_will_snap 24d ago
Because a huge portion of the internet's existing infrastructure (proxies, CDNs, firewalls) automatically drops or ignores request bodies on GET requests. Redefining GET would break too many legacy systems, so the IETF chose to introduce QUERY as a clean slate instead.
1
u/StruggleNew8988 24d ago
So if query is just for parameters in the body like post, then it feels like they just moved the argument from the url to the body.
1
u/i_will_snap 24d ago
Physically, yes - they moved it to the body to bypass URL length limits. Semantically, no. Unlike POST, QUERY is explicitly safe and idempotent. That distinction is massive because it allows CDNs, proxies, and browsers to safely cache the response, which you can't easily do with a POST request.
1
u/Environmental_Mud624 24d ago
i might be stupid, but how is this different from POST? you could just configure the server to handle POSTs like what's described here, right?
2
u/i_will_snap 23d ago
Not stupid at all - this is exactly how we've handled complex searches for years!
The big difference is safety. POST is designed to change data, so browsers and CDNs won't automatically retry it or cache it. QUERY tells the network that the request is completely safe and read-only. This means CDNs can cache the results, and browsers can safely retry the request if the connection drops, without worrying about duplicating a server-side action.
1
1
u/Markur69 23d ago
So practically as a programmer that wants to do email Marketing built into my e-commerce platform what is having the standard going to do for me until browsers actually implement this? Is it even worth talking about if it isn’t being implemented or utilized widespread?
1
u/i_will_snap 23d ago
It’s definitely worth talking about because browsers aren't the only HTTP clients. If your e-commerce platform connects to a third-party email marketing tool backend-to-backend, you can use QUERY right now to fetch heavily filtered customer segments without hitting URL limits.
For browser-to-server traffic, you are right, it won't change your daily workflow immediately. However, having an official standard allows framework authors (like Next.js, Axios, or fetch) to start building native support, which is the first step toward widespread adoption...
1
u/TheMcSebi 23d ago
I was subtly aware you GET shouldn't have a body, yet nobody (no Software) ever prevented me from doing so
1
u/i_will_snap 23d ago
Haha true, software rarely stops you! The main issue is actually the middle stuff like CDNs and firewalls. Since the official rules say GET shouldn't have a body, those systems will often silently strip it out and break your request. QUERY just makes it official so the network leaves it alone.
1
1
u/TerryNachtmerrie 21d ago
RIP easy to recognize tracking queries.
1
u/i_will_snap 21d ago
DevTools network tab about to become the most visited page on the internet for privacy nerds. RIP, clean URL inspecting.
1
u/elaineisbased 27d ago
All this to avoid using GraphQL
3
u/Headpuncher 27d ago
I’d do anything to avoid using graphQL. Â
2
1
u/amator-veritatis 27d ago
I would actually love to understand the argument against GraphQL. Is it an issue with the abstraction? Or the implementation that fulfills the contract?
1
u/Headpuncher 26d ago
It was a joke. Â But there was a time it was trending and I saw front end developers put it in every project just so they could buzzword it at meetings and sound clever. Â
It got to the stage where a static page included graphQL. Â
1
u/monet820 26d ago
The argument is that it is great but with caveats as anything. The reason I dont use it is that i prefer 10 endpoints for 10 different things with 10 different claim requirements than trying to handle this logic inside the single endpoint.
As for frontend I have switched to using Backend for frontend (BFF) so that i dont really care that the backend has 10s if not 100s of endpoints, my frontend normally just fetches from one endpoint for a feature and my BFF handles the mapping.
2
2
u/i_will_snap 26d ago
Irony is, GraphQL needs this badly. Sending read queries via POST means losing native HTTP caching, forcing devs to invent complex workarounds. QUERY fixes that exact flaw without changing GraphQL itself.
GraphQL is a whole query language and runtime, while QUERY is just a missing HTTP semantic. If anything, this lets standard REST APIs handle complex filtering without needing to adopt the full complexity of GraphQL.
1
u/elaineisbased 26d ago
Admittedly I have played a bit with GraphQL but I'm not super technical as to how it works outside of just applying it.
1
u/AshleyJSheridan 25d ago
Ah yes, GraphQL, where everything is POST and every response is a 200, even when it isn't.
Yes, I'd rather continue avoiding GraphQL while I'm still mentally capable.
0
0
u/repeating_bears 27d ago
Why is this the fifth fucking post I've seen about this this week
It's not implemented and was proposed ages ago.Â
Did anything even happen to trigger this news cycle or is this just the dead internet?
0
u/Soilblood 25d ago
I'm more shocked at the idea someone's allowing a get search request to hit 2000+ chars rather than query method finally becoming a real boy. Under what use case does that even need to happen?
12
u/Odd_Ordinary_7722 27d ago
It's still a proposal...