Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose bodyBytes from http.response in client.dart #141

Closed
ifndefdeadmau5 opened this issue Dec 12, 2018 · 8 comments
Closed

Expose bodyBytes from http.response in client.dart #141

ifndefdeadmau5 opened this issue Dec 12, 2018 · 8 comments

Comments

@ifndefdeadmau5
Copy link

ifndefdeadmau5 commented Dec 12, 2018

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

It seems response from server sometimes(in my case, request to apollo-server) isn't decoded properly by http package. So I want to manually decode raw bodyBytes by myself with my own decoding method. Currently client.query only expose that already decoded result as far as I know.

Describe the solution you'd like
A clear and concise description of what you want to happen.

Expose bodyBytes to user.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Couldn't come up with any, yet.

Additional context
Add any other context or screenshots about the feature request here.

Below is just motivation of this feature request, which is unexpected decoding when requesting with 'content-type': 'application/json, charset=utf-8;' from client, 'Content-Type': 'application/json' from server.

image

and guess this is a related issue dart-lang/http#175

@dennisschneider
Copy link

I have exactly the same issue (in my case request to apollo-server-micro), being able to access bodyBytes would be nice.

@ifndefdeadmau5
Copy link
Author

ifndefdeadmau5 commented Dec 12, 2018

@dennisschneider Glad to found another victim here. Are you still having that issue?
I resolved that by setting server response header as 'Content-Type': 'application/json; charset=utf-8' so that dart/http can choose the right encoding

@dennisschneider
Copy link

@ifndefdeadmau5 tried it but that breaks my GraphQL Playground ... will fiddle around with it some more, thank you!

@dennisschneider
Copy link

@ifndefdeadmau5 how did you set the server response header for apollo-server & which implementation are you using ? Tried it with apollo-server-micro & apollo-server-express but apollo seems to override it ... I tried this:
app.use((req, res, next) => { res.append("Content-Type", "application/json; charset=utf-8"); next(); });

@ifndefdeadmau5
Copy link
Author

ifndefdeadmau5 commented Dec 14, 2018

@dennisschneider You're right. I'm using koa implementation and apollo-server forces to set 'Content-Type' to 'application/json' in response header internally. So I was able to set that by modifying package itself, but that is definitely not a clean way to do it.. so still not resolved actually 😭

@dennisschneider
Copy link

dennisschneider commented Dec 14, 2018

@ifndefdeadmau5 finally found a workaround ... I use http-proxy to override the header ... only drawback is that it breaks graphql-playground (but you still can connect with a standalone graphql-playground so not a real issue)

const httpProxy = require("http-proxy");

const proxy = httpProxy
  .createProxyServer({ target: "http://localhost:3000", changeOrigin: true })
  .listen(8000);

proxy.on("proxyRes", function(proxyRes, req, res, options) {
  proxyRes.headers["Content-Type"] = "application/json; charset=UTF-8";
});

@ifndefdeadmau5
Copy link
Author

Thank you @dennisschneider, it works like a charm 👍
Hope apollo-server provide built-in way to do it soon, tho :)

@micimize
Copy link
Collaborator

This seems outdated - I think today this could be resolved with a custom http link, which I think is fine given the niche nature of it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants