Hacker News Reader

Comment by pdpi | Hacker News Reader

A request body in a GET is not standard HTTP. Refusing to handle non-standard requests might be inconvenient, but it's an eminently defensible choice.

I understand why you'd want it, and that's why RFC10008 introduces QUERY as a GET-with-body alternative.

View on HN

Technically every http method can have a body? But the specification says the semantics are undefined on get and any compliant implementation is free to ignore it.

Or any compliant implementation is free to not ignore it like istio/envoy, infrastructure tooling, etc.

What is the use of spec adherence if it leads to unusable/broken applications.

What? The applications are broken, they don’t get to assign meaning to a get body and force every compliant implementation to play along.

Nope. The spec is broken. Hence they were forced to patch the spec with the addition of the QUERY method this year.

Spec is not Bible/Quran requiring religious adherence. If the spec is idiotic, developers have and will circumvent it until either the spec adapts or developers move on abandoning the spec leaving it to rot in the dust.

Notice that it’s a new method because the body on a GET means nothing? So the apps relying on it are broken.

> body on a GET means nothing

Why because a bunch of guys in a committee said so? Sorry your committee is broken if they put idiotic ideas out there in the open asking everybody to conform.

But at this point I don't think you would get it. All hail the almighty spec.

QUERY, added in 2026, does not resolve existing or legacy applications.

Sticking to RFC is one thing. Advertising as node compatible is completely different altogether. Many people cannot see the difference.

Atleast a flag would suffice as that would ensure existing infrastructure tooling doesn't break while keeping the RFC spec folks happy.

Reply on news.ycombinator.com