And it was rather controversial that some listed a body as necessary for a GET request, and doing my research I came to find out that a "request body" was often quite undesirable and perhaps contrary to the RFC standards, and sending a "body" in a GET could result in undefined or unpredictable behavior. But it's all in good fun.
Perhaps the broken thing might be how you expect existing softwares to break so that your expectation can be satisfied. You should look at GET more closely.
There is a reason curl allows to send GET requests with a body. There is a reason node allows to receive GET requests with a body.
I understand why you'd want it, and that's why RFC10008 introduces QUERY as a GET-with-body alternative.
What is the use of spec adherence if it leads to unusable/broken 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.
https://github.com/graphql/graphql-over-http/blob/main/spec/...
The QUERY method is a step in the right direction but it came too late.