The new HTTP QUERY method explained • Hacker News Board

Re: The new HTTP QUERY method explained

#111

Post by nesarkvechnep » Tue, Jun 23, 2026, 12:54 PM UTC

EnnEmmEss wrote: post #69

ramon156 wrote: post #37

"QUERY is just GET" "Using GET with a Body works" Seems like this is going everyone's head. You're not supposed to use GET with a Body, this is a hack, therefore having an explicit method makes sense. Just because it works, doesn't mean its the right way

Using GET with a Body doesn't work if you try using it in the browser with JS fetch for example[1]. Additionally, a lot of existing web servers by default ignore GET requests with a body. The use case of QUERY is because POST conveys non-safe, non-idempotent requests which can potentially modify stuff according to the REST spec. GET requests on the other hand convey retrieval of a resource. However, due to GET reques…

There's no such thing as REST spec. The closes mechanism to actual REST is to create a resource using POST and then query it using GET. You have the added benefit of the resource being cacheable.

Re: The new HTTP QUERY method explained

#112

Post by nesarkvechnep » Tue, Jun 23, 2026, 12:56 PM UTC

I still don't get the need for QUERY. One can create a search or filter resource with a POST request and then query it using GET. As a bonus, creating a resource allows it to be shared and cached.

Re: The new HTTP QUERY method explained

#113

Post by 8-prime » Tue, Jun 23, 2026, 12:57 PM UTC

hparadiz wrote: post #26

echoangle wrote: post #20

Earlier quoted context omitted.

In what role? As a user writing client code or when implementing the caching middleware or the Webserver?

In my CRUD controller that I already have.

This assumes that all of the infrastructure surrounding your application also plays nicely with it and supports it, as stated in the article. That's why I expressed my interest in speed of adoption in the first place.

Re: The new HTTP QUERY method explained

#114

Post by theowaway213456 » Tue, Jun 23, 2026, 12:57 PM UTC

nesarkvechnep wrote: post #112

I still don't get the need for QUERY. One can create a search or filter resource with a POST request and then query it using GET. As a bonus, creating a resource allows it to be shared and cached.

Obviously the approach you mentioned has the downside of two server round-trips being necessary while the QUERY request only requires a single round-trip. Not to mention the two-request approach adds more complexity to both clients and servers, as it mandates that both the client and server have to physically create and manage those resources.

Re: The new HTTP QUERY method explained

#115

Post by entuno » Tue, Jun 23, 2026, 1:04 PM UTC

jefc1111 wrote: post #87

ramon156 wrote: post #37

"QUERY is just GET" "Using GET with a Body works" Seems like this is going everyone's head. You're not supposed to use GET with a Body, this is a hack, therefore having an explicit method makes sense. Just because it works, doesn't mean its the right way

Yep. We had to change our app when we took on a client with a strictly configured WAF which rejected GET with body. I know I have come across multiple points where I have used POST when I know it is wrong, or GET with a body, when I know it is wrong. So I welcome QUERY!

AWS CloudFront blocks GET requests with a body, so it doesn't even have to be a particularly strict setup or an explicit WAF.

Re: The new HTTP QUERY method explained

#116

Post by flanked-evergl » Tue, Jun 23, 2026, 1:05 PM UTC

tosti wrote: post #10

> using HTTP GET with a request body is a bad idea, as for example users behind a corporate firewall or a different browser may be unable to use your website. So is using QUERY requests for quite some time from now.

The fact that some infrastructure is poorly maintained is not a reason against evolving protocols, it's a reason to maintain infrastructure better. It's really not that difficult to do.

Re: The new HTTP QUERY method explained

#117

Post by flanked-evergl » Tue, Jun 23, 2026, 1:07 PM UTC

veltas wrote: post #96

The other issue with adding a separate supported way to do what people did with GET+body is that we will probably see servers slowly drop support for the GET+body approach when QUERY gets widespread support/usage, and then a ton of other stuff will break. Unless you're really going to improve things or the existing practices are really too painful, standards should follow convention. Even though GET+body is not handl…

> Even though GET+body is not handled the same everywhere, it's easier to make that the standard than it is to make a new syntax the standard.

Is there some research or study that you base this claim on? What is the reasoning? Can you elaborate?

Re: The new HTTP QUERY method explained

#118

Post by voiceofunreason » Tue, Jun 23, 2026, 1:07 PM UTC

doginasuit wrote: post #84

Would this be a defensible decision if the spec were designed today, an additional read method that takes the same argument, entirely for the purpose of not ignoring a specific property? It seems like just the path of least resistance considering all the controversy and legacy tools. That is not a good way to maintain the functionality and long-term relevance of a spec. But if there is a good reason to design it this…

My guess is that if you were building all of this from scratch, you would start with

- request-with-a-body

- idempotent-request-with-a-body

- safe-request-with-a-body

because the additional constraints induce properties that are extremely useful to general purpose clients ("I didn't get a reply to my idempotent-request-with-a-body, can I resend it without risking loss of property?")

Would someone then come along an introduce safe-request-without-a-body method? After all, we can already meet that "need" with safe-request-with-a-body and content-length: 0.

Think rfc-5789::PATCH - mechanically, it's just another request-with-a-body, but with more tightly constrained semantics. But general purpose components can take advantage of the additional properties, and so we introduce a "niche" method with tighter constraints.

Document resource manipulation is a common case, so we probably end up with a family of specialized methods, in much the same way that we have a bunch of WebDAV methods.

Re: The new HTTP QUERY method explained

#119

Post by austin-cheney » Tue, Jun 23, 2026, 1:16 PM UTC

It blows my mind that people are invested in this. HTTP is a 35+ year old text-based protocol. Its becoming the COBOL of digital transmission.

Just as one example, among many, you could try WebSockets (or some other similar protocol) and then push anything over it. Your message could be plain text, JSON, binary, whatever. Web Sockets and protobufs are bidirectional (full duplex) too.

Re: The new HTTP QUERY method explained

#120

Post by entuno » Tue, Jun 23, 2026, 1:18 PM UTC

nness wrote: post #105

Asmod4n wrote: post #68

Slightly off topic Funfact: you can buy a several thousand dollars expensive ssl intercepting proxy appliance which doesn’t support anything beyond http/1.1. Will be fun when those see a whole new http verb, I bet that leads to at least DoS by the track record of that company.

What is the use-case for a WAF/proxy/etc. to block unknown HTTP verbs? It feels like a pathway for obsolescence with no actual security benefit?

Historically there have been vulnerabilities in various applications due to HTTP method tampering, and in the days of people accidentally leaving WebDAV enabled then methods like PUT and DELETE could be very damaging. Plus the issues with TRACK and TRACE.

Given that most websites only ever use a handful of methods (even once you account for REST APIs using PUT, PATCH and DELETE now), and that list very rarely changes, the WAF developers tend to look at this question from the opposite angle: when you know there are only half a dozen widely used methods, why would you allow anything else by default?