Comment by elendilm
1 day ago
I never found Deno compelling enough compared to Node.
Bun was promising, but as long as they don't fix their http GET implementation to accept the request body, its broken for me.
Note: Many real world tools like Elasticsearch's GET /_search with a JSON query DSL is one example. It breaks Axios. Many custom infrastructure tools expect it.
Advertising as node compatible and having this breaking change is undesirable. Hope it gets fixed soon.
You shouldn't be sending a body with a GET request. Sounds like your code is broken.
No. There are use cases for GET with body. Curl allows it. Node allows it. Bun doesn't.
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)
no.
5 replies →
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).
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.
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.
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.
3 replies →
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/...
1 reply →
They just implement the fetch api from the web, does the fetch api allow get’s to have a body?
Node allows it. Curl allows. Not having it is a breaking change and undesirable for node compatibility.
If you need bug-for-bug node compatibility you should be using node.
1 reply →
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.
1 reply →