Intended outcome:
The requests are made with the following header:
Content-Type:application/json
Actual outcome:
The requests are made with the following header:
content-type:application/json, application/json
This result in the following error from the server: invalid media type.
One simple work-around is to remove the Content-Type key.
How to reproduce the issue:
import { createHttpLink } from 'apollo-link-http'
const httpLink = createHttpLink({
credentials: 'include', // Send the cookies
compress: true,
headers: {
'Content-Type': 'application/json',
},
})
Did you find a workaround for this one?
One simple work-around is to remove the Content-Type key.
@renatomefi
@oliviertassinari sorry, my problem is another one and I've opened a new issue! :)
Thanks for replying tho
@oliviertassinari I'm curious, why are you setting the content type when it is already set to application/json?
@jbaxleyiii I was migrating to the new version of react-apollo.
@oliviertassinari sorry, I meant did you intent to reset it? The link sets that type for you automatically so you should just not pass anything for content-type
@jbaxleyiii I had to set the value previously, I was assuming the behavior didn't change.
I had this issue as well; would be useful to make note of changes like this in the upgrade guide part of the documentation.
I discovered this same "bug" because I was trying to avoid causing a preflight request. Looking at the source code, I found this:
createHttpLink sets content-type (lowercase). If you set Content-Type (not lowercase), you'll have an object with two keys on it (content-type and Content-Type) after Apollo merges its internal headers with yours (https://github.com/apollographql/apollo-link/blob/master/packages/apollo-link-http/src/httpLink.ts#L237).
As far as I can tell, the fetch implementation then either:
header['content-type'] onto the request (eg. Apollo's)Either way your custom header goes missing unless you correctly handle case insensitivity. See https://github.com/github/fetch/issues/503#issuecomment-307551541 for more context (despite being outdated).
I'm not sure if this is a bug so much as something in need of documentation, warning, or explicit API.
This concludes today's edition of "Fetch header case insensitivity: How deep does the rabbit hole go? Does it go deep? Let's find out!"
Since this issue is really outdated I am closing it but if you are still concerned about this feel free to reopen and I'll get back to you asap.
Most helpful comment
I discovered this same "bug" because I was trying to avoid causing a preflight request. Looking at the source code, I found this:
https://github.com/apollographql/apollo-link/blob/d34eaa3aa178ed5ef8fbff70a45b160324133c36/packages/apollo-link-http/src/httpLink.ts#L219-L223
createHttpLinksetscontent-type(lowercase). If you setContent-Type(not lowercase), you'll have an object with two keys on it (content-typeandContent-Type) after Apollo merges its internal headers with yours (https://github.com/apollographql/apollo-link/blob/master/packages/apollo-link-http/src/httpLink.ts#L237).As far as I can tell, the fetch implementation then either:
header['content-type']onto the request (eg. Apollo's)Either way your custom header goes missing unless you correctly handle case insensitivity. See https://github.com/github/fetch/issues/503#issuecomment-307551541 for more context (despite being outdated).
I'm not sure if this is a bug so much as something in need of documentation, warning, or explicit API.
This concludes today's edition of "Fetch header case insensitivity: How deep does the rabbit hole go? Does it go deep? Let's find out!"