Good use case for graphQL requests which use POST for all queries? But then again what about mutations
Presumably good GraphQL libraries would support requiring POST for mutation and QUERY as acceptable for all queries that don't involve mutation.
The new HTTP QUERY method explained
161–170 of 179 posts
Re: The new HTTP QUERY method explained
#162Earlier quoted context omitted.
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 work…
We can HTTP and all bets are still off, probably.
Do you test with a proxy? I know I don't, and if I would it'd be the latest version of squid.
Some of those non-conforming middle boxes could be unattended black boxes in the back of a closet somewhere on the 3rd floor. Who knows. Some customers would consider alternatives to your offering because it doesn't work, others would file a support ticket and there becomes an incentive not to use the new and shiny. The broken middle black box vendor can't be bothered and keeps selling broken boxes. Shit like this is why we can't have nice things.
Re: The new HTTP QUERY method explained
#163"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 reques…
>Additionally, a lot of existing web servers by default ignore GET requests with a body.
I think the point made is that _all_ existing web servers have no idea what a "QUERY" is anyway, so changes need to be made anyhow.
Re: The new HTTP QUERY method explained
#164Earlier quoted context omitted.
> Even though GET+body is not handled the same everywhere, it's easier to make that the standard than it is to make a new syntax the standard. Is there some research or study that you base this claim on? What is the reasoning? Can you elaborate?
With standards it helps to reconcile existing behaviour, rather than create new unproven syntax. Likewise creating a new syntax for something that already exists means you are just adding to the heap of stuff that needs support on mainstream servers, and as I already said it will probably create compatibility issues as the old deprecated/illegal syntax is removed. This is unnecessary friction. And really what is the…
But it's not existing behaviour. It does not already exist. Breaking the semantics of something that exists means that things will work inconsistently. Breaking the semantics of get will also create compatibility issues.
Re: The new HTTP QUERY method explained
#165Earlier 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.
that's a legit use case. thanks for the info!
Re: The new HTTP QUERY method explained
#166Earlier quoted context omitted.
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 reques…
There's no such thing as REST spec. The closes mechanism to actual REST is to create a resource using POST and then query it using GET. You have the added benefit of the resource being cacheable.
To clarify, by REST spec I meant the state of access defined by https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/....
Re: The new HTTP QUERY method explained
#167Earlier quoted context omitted.
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 reques…
>Additionally, a lot of existing web servers by default ignore GET requests with a body. I think the point made is that _all_ existing web servers have no idea what a "QUERY" is anyway, so changes need to be made anyhow.
Not exactly. OPTIONS lets servers tell you that QUERY is supported if the client requests it and Status Code 405 lets servers tell you that QUERY is not supported. That's very different from the current landscape where several proxy servers and web servers simply ignore the Body of a GET request.
Re: The new HTTP QUERY method explained
#168Earlier quoted context omitted.
With standards it helps to reconcile existing behaviour, rather than create new unproven syntax. Likewise creating a new syntax for something that already exists means you are just adding to the heap of stuff that needs support on mainstream servers, and as I already said it will probably create compatibility issues as the old deprecated/illegal syntax is removed. This is unnecessary friction. And really what is the…
But it's not existing behaviour. It does not already exist. Breaking the semantics of something that exists means that things will work inconsistently. Breaking the semantics of get will also create compatibility issues.
You might want to read the article.
Re: The new HTTP QUERY method explained
#169Earlier quoted context omitted.
> "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.
QUERY won't be supported by them either. So, change is required. Just change GET to allow for body and move on. Most of the systems that are blocking GET/body could be easily tweaked to allow it. Today. As is. QUERY will likely need firmware updates, core engine updates, etc. Meanwhile, tweaking GET is a rule change.
> QUERY won't be supported by them either.
Actually you are quite wrong. HTTP already accommodaties nonstandard methods, so HTTP-compliant servers do support whatever string you put together as the method.
What you are failing to understand is that this proposal defines both a method and its semantics. This means the expected behavior regarding idempotency, safety, cacheabiliry. Nonstandard methods by design are interpreted as being unsafe.
What you are also failing to understand is that GET is explicitly designed to not have a request body. This means that a GET with a body is interpreted as something that violates specifications and is potentially an attack such as request smuggling. Again, some API gateways strip them as a security precaution.
> Most of the systems that are blocking GET/body could be easily tweaked to allow it. Today. As is.
Utter nonsense. You are talking about things like home routers and old phones.
> QUERY will likely need firmware updates, core engine updates, etc.
Not really, only if those devices do not comply with HTTP.
The real value proposition is the semantics of a QUERY operarion regarding safety and caching. It's not a coincidence that this proposal is backed by the likes of Cloudflare. All HTTP compliant requests are just forwarded through all internet boxes, and the likes of Cloudflare sits at the edge safely caching them.
Re: The new HTTP QUERY method explained
#170Earlier quoted context omitted.
QUERY won't be supported by them either. So, change is required. Just change GET to allow for body and move on. Most of the systems that are blocking GET/body could be easily tweaked to allow it. Today. As is. QUERY will likely need firmware updates, core engine updates, etc. Meanwhile, tweaking GET is a rule change.
Yeah I really don't understand the anti-GET-body argument. "Using GET with a body isn't in the spec, WAFs and webservers that haven't been updated might reject it!" Ok, QUERY wasn't in the spec when those were written either. What do you expect those appliances to do with a totally unknown verb? It's a welcome addition but the new method is pure marketing. There's no reason the update couldn't have been to expand GET…
> Using GET with a body isn't in the spec,
It's exactly the opposite. The HTTP spec does cover GET with bodies. However, what you fail to account is that the spec specifies they are invalid and a GET with body is meaningless, and represents a potential attack.