upvote

points

by elendilm21 hours ago |
comments
upvoteby HumanOstrich21 hours ago|
next
[-]
You shouldn't be sending a body with a GET request. Sounds like your code is broken.
reply
upvoteby elendilm20 hours ago|
parent|
[-]
No. There are use cases for GET with body. Curl allows it. Node allows it. Bun doesn't.
reply
upvoteby chiffaa18 hours ago|
parent|
next
[-]
There may be use-cases (and the RFC allows ignoring the SHOULD clause with enough reasoning), but GET does not have a request body as per specification, and a LOT of things drop it because of that (most notably - nginx! Also applies to HAProxy and Apache HTTP server afaik, but also a bunch of load balancers)
reply
upvoteby ericlewis20 hours ago|
parent|
prev|
[-]
no.
reply
upvoteby elendilm19 hours ago|
parent|
[-]
Wrong.

Hint: Elasticsearch, GraphQL, Axios, etc..

reply
upvoteby a5772117 hours ago|
parent|
[-]
GraphQL uses POST for queries.
reply
upvoteby elendilm16 hours ago|
parent|
[-]
Many GraphQL clients/libraries use GET with body to workaround hitting URL query limitations like length, etc.

Spec is not the same as compatibility.

reply
upvoteby pipe0110 hours ago|
parent|
[-]
How would you hit URL query limitations when putting your GraphQL query in the POST request's body?
reply
upvoteby elendilm7 hours ago|
parent|
[-]
[dead]
reply
upvoteby zahlman20 hours ago|
prev|
next
[-]
Enabling the GET implementation to "accept the request body" would literally be the opposite of fixing it. The broken thing here is your expectation. You are looking for POST (or possibly PUT).
reply
upvoteby ButlerianJihad20 hours ago|
parent|
next
[-]
It was funny a few years ago, when I had to grade students answering a quiz about web services. There was a question about which components were necessary for a valid GET request. The required answer was a list of 4-5 components, such as the "GET" verb, the URI, the HTTP version, etc.

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.

reply
upvoteby elendilm20 hours ago|
parent|
prev|
[-]
You would be surprised how many technologies expect GET with a body. In practical backend engineering, tools like Elasticsearch, GraphQL, complex query engines, and legacy internal APIs rely on GET with a body every day. Apparently even axios messes up on curl GET requests with a body as mentioned in the associated github issue.

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.

reply
upvoteby pdpi19 hours ago|
parent|
next
[-]
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.

reply
upvoteby what19 hours ago|
parent|
next
[-]
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.
reply
upvoteby elendilm7 hours ago|
parent|
[-]
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.

reply
upvoteby elendilm16 hours ago|
parent|
prev|
[-]
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
upvoteby jazzypants10 hours ago|
parent|
prev|
[-]
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.

https://github.com/graphql/graphql-over-http/blob/main/spec/...

reply
upvoteby elendilm8 hours ago|
parent|
[-]
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.

The QUERY method is a step in the right direction but it came too late.

reply
upvoteby zja20 hours ago|
prev|
[-]
They just implement the fetch api from the web, does the fetch api allow get’s to have a body?
reply
upvoteby elendilm20 hours ago|
parent|
[-]
Node allows it. Curl allows. Not having it is a breaking change and undesirable for node compatibility.
reply
upvoteby dullcrisp19 hours ago|
parent|
next
[-]
If you need bug-for-bug node compatibility you should be using node.
reply
upvoteby elendilm17 hours ago|
parent|
[-]
Your "bug-for-bug" compatibility ensures Axios, Elasticsearch, many GraphQL implementations, etc. works. Hence I will use node as mentioned in my original comment.

You should use bun :)

reply
upvoteby what19 hours ago|
parent|
prev|
[-]
A body is technically allowed on any http request but it doesn’t mean anything on a get, a server is free to ignore it, anything in the middle is free to strip it, etc.
reply
upvoteby elendilm7 hours ago|
parent|
[-]
And yet many don't, Istio/Envoy for example. There are enough usable applications that utilize it that ignoring the body comes with a cost.
reply