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.
replyI understand why you'd want it, and that's why RFC10008 introduces QUERY as a GET-with-body alternative.
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.
replyOr any compliant implementation is free to not ignore it like istio/envoy, infrastructure tooling, etc.
replyWhat is the use of spec adherence if it leads to unusable/broken applications.
QUERY, added in 2026, does not resolve existing or legacy applications.
replySticking 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.
I can't speak for any of these other technologies, but no part of the GraphQL spec requires GET requests to have bodies. The spec is clear about how to use query strings instead.
replyhttps://github.com/graphql/graphql-over-http/blob/main/spec/...
As I have noted elsewhere here in this thread, spec saying one thing has nothing to do with how many libraries implement something. If the libraries are critical and provide value, then no matter how much you scream for your adherence to the spec, people will use it and depend on it.
replyThe QUERY method is a step in the right direction but it came too late.