The new HTTP QUERY method explained • Hacker News Board

Re: The new HTTP QUERY method explained

#11

Post by unilynx » Tue, Jun 23, 2026, 8:13 AM UTC

dreambigwrkhard wrote: post #6

koolala wrote: post #5

What do you think people will make the Query request body? Most everything will use this for JSON but it could be anything so what other interesting things do you think will go in there? Query 1 + 1 and get 2?

I'm curious too. Unless the developer is really passionate about this I don't think a dev will risk (potential) compatibility issues or unexpected footguns to use this when the workarounds do seem to work quite well already. I just dont see the benefit but maybe it's because I am just not aware of a real world use case; happy to be corrected.

Elastic/Opensearch uses GET requests with a body for search, which is complicated or forbidden (not exactly sure) with the HTTP spec. Not all HTTP clients are willing to submit a body with a GET.

So opensearch also allows you to POST search requests, but those are uncacheable

QUERY would fit here perfectly - it's probably trivial for opensearch to add but it will take some time for clients to catch up.

Re: The new HTTP QUERY method explained

#12

Post by rmunn » Tue, Jun 23, 2026, 8:16 AM UTC

hparadiz wrote: post #8

flanked-evergl wrote: post #4

Earlier quoted context omitted.

No, it does not feel like that.

My framework is already two decade old prior art and you still haven't actually convinced me that this RFC solves a problem.

1. Sometimes you need a request body. 2. POST cannot be guaranteed to be safe if re-sent. 3. This is GET with a request body, guaranteed* to be safe if re-sent.

* With the caveat that it's only guaranteed if the server is following the RFC correctly.

Re: The new HTTP QUERY method explained

#13

Post by doctor_phil » Tue, Jun 23, 2026, 8:20 AM UTC

Nice, not having bodies on GET has been a pet peeve of mine for a long time. It would be nice to allow bodies on DELETE as well, but that is less of a problem in most cases.

Re: The new HTTP QUERY method explained

#14

Post by LaGrange » Tue, Jun 23, 2026, 8:24 AM UTC

rmunn wrote: post #12

hparadiz wrote: post #8

Earlier quoted context omitted.

My framework is already two decade old prior art and you still haven't actually convinced me that this RFC solves a problem.

1. Sometimes you need a request body. 2. POST cannot be guaranteed to be safe if re-sent. 3. This is GET with a request body, guaranteed* to be safe if re-sent. * With the caveat that it's only guaranteed if the server is following the RFC correctly.

I will keep using POST and not some weird thing that isn’t supported by a proxy living in the basement of a shoe store in Wageningen or whatever.

Re: The new HTTP QUERY method explained

#15

Post by jbverschoor » Tue, Jun 23, 2026, 8:24 AM 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.

Yeah, query seems just GET with a body. No difference in protocol nor behavior

Re: The new HTTP QUERY method explained

#16

Post by nokeya » Tue, Jun 23, 2026, 8:25 AM UTC

If it needs so much explanation and discussion, maybe it is not a great idea after all?

Re: The new HTTP QUERY method explained

#17

Post by PunchyHamster » Tue, Jun 23, 2026, 8:26 AM UTC

8-prime wrote: post #7

It's interesting to see additions to HTTP methods as it much feels like the existing ones are set in stone. At least for the time that I have been a developer. I'm curious to see how fast the adoption/support for HTTP QUERY will be. I've had my fair share of situations where I wished for something like HTTP QUERY.

zero. Many libs will/can just request method as a string so you can start coding now

> I've had my fair share of situations where I wished for something like HTTP QUERY.

Using POST instead comes with no drawbacks

Re: The new HTTP QUERY method explained

#18

Post by PunchyHamster » Tue, Jun 23, 2026, 8:27 AM UTC

rmunn wrote: post #12

hparadiz wrote: post #8

Earlier quoted context omitted.

My framework is already two decade old prior art and you still haven't actually convinced me that this RFC solves a problem.

1. Sometimes you need a request body. 2. POST cannot be guaranteed to be safe if re-sent. 3. This is GET with a request body, guaranteed* to be safe if re-sent. * With the caveat that it's only guaranteed if the server is following the RFC correctly.

> POST cannot be guaranteed to be safe if re-sent.

It can absolutely be guaranteed. What it can't be is communicated to be safe so browser gonna ask its silly question

Re: The new HTTP QUERY method explained

#19

Post by reddalo » Tue, Jun 23, 2026, 8:35 AM UTC

nokeya wrote: post #16

If it needs so much explanation and discussion, maybe it is not a great idea after all?

The article describes the current situation first. The whole explanation is quite simple: QUERY requests are the same as GET, but they have a body.

Re: The new HTTP QUERY method explained

#20

Post by echoangle » Tue, Jun 23, 2026, 8:37 AM UTC

hparadiz wrote: post #9

8-prime wrote: post #7

It's interesting to see additions to HTTP methods as it much feels like the existing ones are set in stone. At least for the time that I have been a developer. I'm curious to see how fast the adoption/support for HTTP QUERY will be. I've had my fair share of situations where I wished for something like HTTP QUERY.

I can implement it in about 10 minutes. Not even kidding.

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