back

by locknitpicker·1mo ago·view on hn ↗
> "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.

1 comments
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 instead of add support for QUERY.

> What do you expect those appliances to do with a totally unknown verb?

405 Method Not Allowed

We have existing standards for unsupported methods.

> 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.

Sure but 405 Method Not Allowed is a response you can fallback from, whereas "body was silently stripped by a middlebox" is not as easy to know when it happens, much less deal with.
> 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.