apollo-link-http: Content-Type

Created on 15 Nov 2017  路  10Comments  路  Source: apollographql/apollo-link

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',
  },
})
bug

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

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:

  • just straight up copies header['content-type'] onto the request (eg. Apollo's)
  • normalises to lowercase and throws out dupes, leaving 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!"

All 10 comments

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:

https://github.com/apollographql/apollo-link/blob/d34eaa3aa178ed5ef8fbff70a45b160324133c36/packages/apollo-link-http/src/httpLink.ts#L219-L223

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:

  • just straight up copies header['content-type'] onto the request (eg. Apollo's)
  • normalises to lowercase and throws out dupes, leaving 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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ash0080 picture ash0080  路  4Comments

NicholasLYang picture NicholasLYang  路  4Comments

ChenRoth picture ChenRoth  路  4Comments

steffenmllr picture steffenmllr  路  4Comments

Kisepro picture Kisepro  路  4Comments