Closed aleksdao closed 7 years ago
It appears this was just a mistake on my part! If I'm reading this correctly (https://github.com/apollographql/apollo-client/blob/3b5045dfe74183fe060d2027e31317d890755b99/src/transport/networkInterface.ts#L189), the Apollo client calls JSON.stringify on the my query... so I should in fact be sending the default content-type: application/json header in my request.
After removing application/graphql override, this works as expected. Thanks for your help!
Yeah - we've made a somewhat intentional decision to not support the application/graphql
content type, since it just makes server implementations and other tools more complex by adding another branch in addition to GET and POST with JSON.
However, it would be great to have at least an error printed if you try to set a different header for that - do you think that would have been helpful?
Hey Sashko - thx for getting back to me. Agree a dev-friendly error message would've been helpful, though I realize I sort of botched the whole setting headers thing.
I set req.options.headers['content-type'] = 'application/graphql'
. For whatever reason, this gets merged with the default Content-Type
header to create a Content-Type: application/json application/graphql
mega-header.
On the other hand, if I set req.options.headers['Content-Type'] = application/graphql
(Content-Type
is capitalized), this overrides the default header as expected, and the Apollo client sends a request with Content-Type: application/graphql
(I'm aware this wouldn't have worked anyways)
Hey there, i am setting content-type header of my request to 'application/keyauth.api.v1', but it's overridden Apollo Client's default content-type 'application/json' header.
const restLink = new RestLink({
uri: process.env.REACT_APP_API_SERVER + process.env.REACT_APP_API_SERVER_VERSION,
credentials: 'omit',
})
const authRestLink = new ApolloLink((operation, forward) => {
operation.setContext(async ({headers}) => {
return {
headers: {
...headers,
Accept: "application/json",
'Content-Type': 'application/keyauth.api.v1',
Authorization: localStorage.getItem('token') ? 'Bearer ' + localStorage.getItem('token') : ""
}
};
});
return forward(operation);
});
const link = ApolloLink.from([
authRestLink,
restLink,
]);
const cache = new InMemoryCache()
const client = new ApolloClient({
link,
cache,
})
@jbaxleyiii great meeting you at the GraphQL NYC meetup last night! Really enjoyed yours and Sashko's talks on the innovation within the Apollo + GraphQL ecosystem - this schema stitching (local+remote, remote+remote) stuff is wild and exciting.
We chatted briefly yesterday about the issue I was having with overriding the default content-type
application/json
header that is set by Apollo Client. If you have any thoughts on the best way to resolve this, let me know! I'm happy to contribute back a PR to extend the client's flexibilityIntended outcome:
Additional context here: https://github.com/Yelp/yelp-fusion/issues/278#issuecomment-322328370
I'm attempting to make a request to the Yelp GraphQL API server by setting a content-type header of
application/graphql
(as suggested by the Yelp GraphQL docs for sending raw GraphQL queries, https://www.yelp.com/developers/graphql/guides/requests)query
Expected Result: response from Yelp GraphQL API with valid restaurant data
Actual outcome:
Instead of overriding the default
content-type: application/json
header, the Apollo client appears to prependapplication/json
to the specifiedapplication/graphql
value. This results in a concatenatedcontent-type: application/json, application/graphql
header.The result of this request is a malformed
content-type
header, to which the Yelp GraphQL API responds withMust provide query string.
Other observations
In Postman,
the Yelp GraphQL API responds with the expected data if
content-type: application/graphql
setthe Yelp GraphQL responds with "Must provide query string" error if
content-type: application/json, application/graphql
setVersion