与Chrome和Firefox POST通话的内容类型不同

Question

Below is the call that I make to the Rest API.It is just the part of the bigger script.

SomeServiceService.addNewCall = function(data)
    {

      deferred = $q.defer();
      addNewPaymentMethodsServiceCall  = $http({
        url: rootUrl + 'user/v1/something',
        method: 'POST',
        data: data,
        headers: {
          'Content-Type': 'application/json',
          'Accept-Language': 'en-us'
        }
      }).success(function(response){
        deferred.resolve(response);
      }).error(function(response,status){
        response.status= status;
        deferred.reject(response);
      });
      return deferred.promise;
    };

The issue I am having it the difference in Content-Type in chrome and firefox.

In chrome

Accept-Language:en-US
Cache-Control:no-cache 
Content-Type:application/json
If-Modified-Since:Mon, 26 Jul 1997 05:00:00 GMT
Origin:https://mydomain 
Pragma:no-cache
Referer:mydomain/users/app/
User-Agent:Mozilla/5.0(Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143
Safari/537.36

In Firefox

Accept  text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding  gzip, deflate
Accept-Language  en-US 
Cache-Control    no-cache 
Connection       keep-alive 
Content-Length   157 
Content-Type     application/json; charset=UTF-8 
Host             mydomain 
If-Modified-Since    Mon, 26 Jul 1997 05:00:00 GMT 
Pragma           no-cache 
Referer          https://mydomain/users/app/ 
User-Agent       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:43.0)     Gecko/20100101 Firefox/43.0

Even though in the ajax call I am explicitly declaring the Content-type as application/json firefox adds the charset-UTF-8 which breaks my API call since the API only supports application/json .

How can I make firefox not change the Content-Type? This only happens for POST,PUT.

Any suggestions or help is appreciated.

Answer 1

Quentin's answer above is correct:

You should really fix the API. In 2016 it should be able to cope with having a parameter on the content-type.

We had the same issue today and solved it by changing the API: instead of checking whether the content-type equals 'application/json', we check whether the content type contains that string.

Specific code is language-specific, but for Python (using the Falcon REST framework) it was a matter of replacing

if req.content_type == 'application/json':

with

if 'application/json' in req.content_type: