Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The new HTTP QUERY method explained

kreya.app

Post reply on HN
Print view View original

101–110 of 179 posts

Re: The new HTTP QUERY method explained

#101

Post by topham »

unilynx wrote: post #11
dreambigwrkhard wrote: post #6

Earlier quoted context omitted.

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.

Fixing GET would be easier.

And yes,it would be fixing a flawed interpretation of what should be implemented.you are, by definition GETting something.

Tools dropping body from GET by default are violating the spec today.

Rules configured to drop it are just that, temporarily configured constraints readily modified.

Adding QUERY will make it unpredictable in effectively the same manner as GET/body. It'll take even longer to resolve it though.

Re: The new HTTP QUERY method explained

#102

Post by stymaar »

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

You're missing the point. Using GET with a body is currently unspecified, so of course you're not supposed to do it (though you're not forbidden to either).

But specifying this behavior would get you in the same situation as adding a new method: everything not up to date with the spec will keep behaving poorly but newer system would work.

The only benefit of adding a new method is for marketing/awareness: it may end up getting support faster than the alternative because it sounds as a sexy new thing to implement. This kind of benefit should not be overlooked, but we should also acknowledge its limits: most of enterprise stuff (WAF, frameworks, etc.) are not going to work overnight just because it's a new method instead of a spec change.

Re: The new HTTP QUERY method explained

#103

Post by kortex »

hparadiz wrote: post #72
flanked-evergl wrote: post #52

Earlier quoted context omitted.

What does "some random third party" have to do with any of it? An SQL server can expose HTTP directly. SQL is not the only query language that exists. SPARQL's standard protocol for sending Queries uses HTTP[1], and yes, of course it allows clients to define the query that it sends over HTTP. HTTP QUERY would be ideal for SPARQL queries. There are also many unprotected SPARQL endpoints that you can use without any au…

This thread is for an RFC that is less than 3 pages and solves no problems that exist. I'm tired of having to pretend like every idea on the internet is a good one.

This RFC (the concept behind it) has been in the works in one form or another since 2008

> The HTTP SEARCH method was first formally proposed in November 2008 within RFC 5323.

> Before it became a full RFC, the proposal progressed through the IETF under the working group draft name draft-ietf-httpbis-safe-method-w-body. Its formal journey began in March 2021 as an adaptation of the older SEARCH method (from WebDAV's RFC 5323), before being renamed explicitly to QUERY in later draft revisions.

There's no "pretending" this is a good idea, a ton of very smart people have spent a tremendous amount of effort refining this solution. It's incredibly well thought out.

Re: The new HTTP QUERY method explained

#104

Post by topham »

dxdm wrote: post #66
someguynamedq wrote: post #22

Earlier quoted context omitted.

So just add an optional body to get

The article also addresses why this is not the chosen solution. It's pretty much the first one you'd think of: all kinds of existing software (that can be between client and server and out of their control) already handle GET bodies in all kinds of incompatible ways, because the existing standard says they're meaningless and "shouldn't" be included. The idea is to not break people's stuff, so they don't rugpull the e…

So, I need to update all the tools to support QUERY, or I need to update all the tools to support GET/body.

So, either way, I need to update all the tools.

Just fix GET.

Re: The new HTTP QUERY method explained

#105

Post by nness »

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?

Re: The new HTTP QUERY method explained

#107

Post by Asmod4n »

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?

Not block, straight out crash the process is my guess will happen here.

Re: The new HTTP QUERY method explained

#108

Post by hparadiz »

kortex wrote: post #103
hparadiz wrote: post #72

Earlier quoted context omitted.

This thread is for an RFC that is less than 3 pages and solves no problems that exist. I'm tired of having to pretend like every idea on the internet is a good one.

This RFC (the concept behind it) has been in the works in one form or another since 2008 > The HTTP SEARCH method was first formally proposed in November 2008 within RFC 5323. > Before it became a full RFC, the proposal progressed through the IETF under the working group draft name draft-ietf-httpbis-safe-method-w-body. Its formal journey began in March 2021 as an adaptation of the older SEARCH method (from WebDAV's…

The test of an RFC is whether people use it. Your example doesn't inspire confidence.

Re: The new HTTP QUERY method explained

#110

Post by dotancohen »

4gotunameagain wrote: post #106
dotancohen wrote: post #45

Earlier quoted context omitted.

Intermediate proxies, caches, CDNs, firewalls, and load balancers.

That is only in the case of GET with a body though.

Yes. That is the issue under discussion, e.g. not "classic GET".
Post reply on HN