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

51–60 of 179 posts

Re: The new HTTP QUERY method explained

#51

Post by jagged-chisel »

tosti wrote: post #33
jy14898 wrote: post #25

Earlier quoted context omitted.

405 Method Not Allowed is trivial to fall back to POST. How do you know the GET request behaved incorrectly?

That's assuming the corporate proxy is well-behaved.

Then all bets are off, and I guess we just can’t HTTP ever again because a proxy can misbehave.

One should adhere to Best Practices since one cannot control every device between the app and the user. Best Practice says “GET has no body. QUERY can have a body. If QUERY fails (405), use POST with the body.” And eventually, enough proxies will behave well enough that at least the HTTP bit of the app has a chance of working.

Re: The new HTTP QUERY method explained

#52

Post by flanked-evergl »

hparadiz wrote: post #29
flanked-evergl wrote: post #28

Earlier quoted context omitted.

> For one you would never allow a client to dictate the query. That is a security and validation problem. So you have to deconstruct the query anyway and then rebuild it. Every single SQL server allows a client to dictate the query. Furthermore, not all queries are SQL queries.

[flagged]

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 authentication [2][3].

[1]: https://www.w3.org/TR/sparql11-protocol/#query-operation

[2]: https://sparql.dblp.org/

[3]: https://data.europa.eu/en/about/sparql

Re: The new HTTP QUERY method explained

#53

Post by ronbenton »

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

I’ve seen a framework strip body content off GET requests, so doing hacky things doesn’t even always work. The QUERY method is a welcome addition

Re: The new HTTP QUERY method explained

#56

Post by braiamp »

waweic wrote: post #21

I wonder what the drawbacks of standardizing a GET body would have been. CoAP already has it (which creates friction in building CoAP HTTP proxies). All in all, I dislike the overall focus on the HTTP method when designing "RESTful" interfaces. If all we're building is, effectively, an RPC, why would the cacheability meta-information be the first thing we specify?

A absolute swats of middle boxes that will not get addressed ever. As industry, it's preferable to create something that is a hard break and makes players upgrade and give people a feature to argue for said upgrade

Re: The new HTTP QUERY method explained

#57

Post by CodesInChaos »

_alphageek wrote: post #49

>> QUERY request can be cached I have a weird feeling. Query body is encrypted by https. So CDN will not be able to cache results. In order to make it work right - whole topology of the internet should be redone. Caching on the backend server will not give any real gains for large scale apps.

The whole connection is encrypted by https, the request body is treated the same as the url, the headers or the response. The only unencrypted parts are the IP addresses/ports and the domain name (if SNI without ECH is used).

CDNs already terminate TLS connections so they can cache GET requests.

Re: The new HTTP QUERY method explained

#59

Post by antiloper »

hparadiz wrote: post #24
rmunn wrote: post #12

Earlier quoted context omitted.

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 read the RFC front to back. It is lazy. To the point where I'd be embarrassed to even show it to people. For one you would never allow a client to dictate the query. That is a security and validation problem. So you have to deconstruct the query anyway and then rebuild it. That's HTTP APIs 101. Now if the authors of this RFC knew what they were doing they could enforce trust with some sort of JWT like trust mechani…

Yes servers have to validate input data... This isn't new...

Re: The new HTTP QUERY method explained

#60

Post by _flux »

jbverschoor wrote: post #15
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

There is the Accept-Query header https://www.rfc-editor.org/info/rfc10008/#appendix-A.3 that tells you can use QUERY. That's a bit different.
Post reply on HN