Fetch adds charset=utf-8 on Android but not on iOS

[dstaver]

This fetch request sends "application/json" as ContentType on IOS but "application/json; charset=utf-8" on Android:

fetch(url, {
    method: 'POST',
    headers: {
        'Accept': 'application/json',
        'Content-Type': 'application/json',
    }
})

The server I'm working against requires application/json and fails when charset is added. I've filed a bug report with them too, but shouldn't fetch behave identically on ios and android?

[dstaver]

http://stackoverflow.com/questions/25560601/how-to-suppress-charset-being-automatically-added-to-content-type-in-okhttp

[etodanik]

I'm also experiencing this. Having different headers between platforms doesn't make sense and introduces bugs

[lacker]

What's the right thing to do here - should the charset be appended or not?

[himelnagrana]

Having the same issue while working with Urban Airship APIs. Frustrating as UA supposed to be not changing at their end. What to do?

[nalejandroveron]

Im also seeing this

[ide]

What's the right thing to do here - should the charset be appended or not?

Looking at Chrome, it doesn't modify the content-type header at all so we shouldn't be adding a charset.

[alterx]

I'm also experiencing this issue, somehow charset=utf-8 is added as a parameter to the Content-Type header. It only happens on Android. Also, not using fetch but the XMLHttpRequest polyfill that comes with ReactNative by default.

In my specific case, I'm interacting with a JSON API (http://jsonapi.org/format/) and adding media type parameters causes the server to respond with a 415 error every time. This pretty much breaks the app :(

Edit:

I've debugged deep down into react-native/Libraries/BatchedBridge/NativeModules.js:

function genMethod(moduleID: number, methodID: number, type: MethodType) {
  let fn = null;
  if (type === 'promise') {
    fn = function(...args: Array<any>) {
      return new Promise((resolve, reject) => {
        BatchedBridge.enqueueNativeCall(moduleID, methodID, args,
          (data) => resolve(data),
          (errorData) => reject(createErrorFromErrorData(errorData)));
      });
    };
  } else if (type === 'sync') {
    fn = function(...args: Array<any>) {
      return global.nativeCallSyncHook(moduleID, methodID, args);
    };
  } else {
    fn = function(...args: Array<any>) {
      const lastArg = args.length > 0 ? args[args.length - 1] : null;
      const secondLastArg = args.length > 1 ? args[args.length - 2] : null;
      const hasSuccessCallback = typeof lastArg === 'function';
      const hasErrorCallback = typeof secondLastArg === 'function';
      hasErrorCallback && invariant(
        hasSuccessCallback,
        'Cannot have a non-function arg after a function arg.'
      );
      const onSuccess = hasSuccessCallback ? lastArg : null;
      const onFail = hasErrorCallback ? secondLastArg : null;
      const callbackCount = hasSuccessCallback + hasErrorCallback;
      args = args.slice(0, args.length - callbackCount);
      BatchedBridge.enqueueNativeCall(moduleID, methodID, args, onFail, onSuccess);
    };
  }
  fn.type = type;
  return fn;
}

and, even here the Content-Typeheader remains untouched what leads me to think that is the native code in Android what's adding the charset=utf-8

[laurent22]

I'm also having this problem and, while doing some testing, I've tried setting an invalid charset "dropbox-cors-hack" (as I'm testing the Dropbox API) so the request was like this:

apiRequest = request.post(getBaseURL(host) + path)
  //.type('application/octet-stream;')
  .type('text/plain; charset=dropbox-cors-hack')
  .set('Authorization', 'Bearer ' + accessToken)
  .set('Dropbox-API-Arg', httpHeaderSafeJson(args));

When doing so I got the following exception:

And that lead me to this file from the okhttp library:

https://github.com/square/okhttp/blob/master/okhttp/src/main/java/okhttp3/RequestBody.java#L53

So it seems it appends "charset=utf-8" if the charset is not set. I'm not sure if this is React-Native that is calling this lib or if it's Android, but is there anything that can be done to prevent this behaviour?

[laurent22]

Based on this comment it doesn't look like it will be fixed on the okhttp side:

square/okhttp#3081

They suggest using the create overload that takes a byte[] parameter. Can it be done at the React-Native level?