What are the chances sites start using this to prevent sharing links...
With some post websites (banking) and spa already present.
The new HTTP QUERY method explained
81–90 of 179 posts
Re: The new HTTP QUERY method explained
#82Body is already optional with GET. Proxies aren't supposed to touch it or assign meaning to it; it's between the client and the end server. A whole new method whose semantics don't really fit with the others is.. An odd way forward.
Proxies are allowed to drop bodies of HTTP GET requests. RFC 9110 states: > [..] content received in a GET request has no generally defined semantics, cannot alter the meaning or target of the request [..] > A client SHOULD NOT generate content in a GET request [..]
> ... unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported.
You left out the important part.
Re: The new HTTP QUERY method explained
#83"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
Some security/ API gateway block requests when it's a GET with a body.
Re: The new HTTP QUERY method explained
#84Would 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 way from the beginning, I'm curious to know more.
Re: The new HTTP QUERY method explained
#85"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 works"
Except it doesn't. Some API gateways outright strip request bodies from GET requests to prevent them from being forwarded.
It sounds like most people with the "just use GET" nonsense are far from having any experience in cloud computing.
Re: The new HTTP QUERY method explained
#86This breaks rest/crud.
So what?
This is about HTTP.
And it does not break REST: None of the HTTP constructs that REST is built on change due to the introduction of QUERY.
Yes: If you're doing QUERY, you're (potentially) not doing CRUD.
But this enables a clean way to do CQRS over HTTP.
Re: The new HTTP QUERY method explained
#87"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!
Re: The new HTTP QUERY method explained
#88>> 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.
Even past the TLS point (CDNs terminate TLS, so they can read the body) there's a harder problem nobody's solved: to cache a QUERY the cache has to fold the body into the cache key, and there's no standard way to canonicalize a request body. {"a":1,"b":2} and {"b":2,"a":1} are the same query and two different cache entries; whitespace, float formatting, unordered keys all fork the key. GET gets this for free because the URL is already a normalized string. So "cacheable in principle" is real, but "actually cached" needs every layer to agree on a canonical form first - the same coordination problem that killed GET-with-body. I want QUERY for the honest semantics; I just wouldn't budget for cache hits yet
Re: The new HTTP QUERY method explained
#89It'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
Much harder to get CDN:s/proxies/etc to cache a post request vs this new one (assuming it’s actually becomes used)
Re: The new HTTP QUERY method explained
#90Earlier quoted context omitted.
Yeah, query seems just GET with a body. No difference in protocol nor behavior
The difference is the method. Query you're saying I can use body. GET you should never use body.
> The difference is the method. Query you're saying I can use body. GET you should never use body.
The biggest win is how intermediary boxes now have concrete guidance that a specific HTTP request is both safe, idempotent, and carries a request body. Up until now none of this existed, and at best developers could use unsafe methods to carry request bodies (see GraphQL and how it uses POST for queries)