Will this be compatible with graphql?
The new HTTP QUERY method explained
61–70 of 179 posts
Re: The new HTTP QUERY method explained
#62"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
The whole stack is a pile of badly designed hacks. Not much point in fixing it now. I mean they can’t even spell referrer correctly.
Re: The new HTTP QUERY method explained
#63Earlier 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.
> 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
You can guarantee it to yourself, sure, but the talk is about different guarantees, those which are implied by people who has no idea about your plans and opinions but whose software may interact with yours.
Re: The new HTTP QUERY method explained
#64OK, but stop trying to make fetch happen.
Re: The new HTTP QUERY method explained
#65"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
Insofar as I'm concerned, a GET request with a body is an attack-shaped aberration. E.g. Somebody who's trying to get me to mix up validating query string parameters and request body parameters.
Hacky things not working is a feature, not a bug.
Re: The new HTTP QUERY method explained
#66Earlier quoted context omitted.
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.
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 established standard.
There's usually a reason why the simplest solution that pops into one's head is not "just" used by the people who put a lot more thought into it. Not always, but it can be useful to try to come up with it.
Re: The new HTTP QUERY method explained
#67"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
Is the stripper service in question already implementing it?
Re: The new HTTP QUERY method explained
#68Slightly 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.
Re: The new HTTP QUERY method explained
#69"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 requests not having a body, there's a limit to the amount of data you can put in the URL and you also cannot put sensitive data in it.
Additionally, GET requests are meant to be highly cacheable by default while a lot of the QUERY type requests are usually meant more for one-shot access.
QUERY is meant to address these limitations.
Re: The new HTTP QUERY method explained
#70Body 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 [..]
Even HTTP 1.0 RFC[11] is fairly clear on this, although it doesn't explicitly spell it out like RFC 9110. GET requests should only consider the Request-URI and request bodies should only be included if the method calls for it.