Skip to main content

Bug Tracker

Side navigation

#13880 closed bug (notabug)

Opened May 10, 2013 01:53PM UTC

Closed May 10, 2013 05:56PM UTC

Last modified May 13, 2013 09:58AM UTC

contentType not taken into account in .ajax()

Reported by: Markus.Staab Owned by:
Priority: low Milestone: None
Component: ajax Version: 1.9.1
Keywords: Cc: jaubourg
Blocked by: Blocking:

contentType parameter is not handled properly when using .ajax() with some data.

the simplest case I could come up with is


Immediately after reducing all properties from the data object the contentType works as expected.

Tested on Versions 1.8.3, 1.9.0, 2.0, 2.0-edge; all are affected.

Attachments (0)
Change History (10)

Changed May 10, 2013 01:57PM UTC by Markus.Staab comment:1

Tested on FF22a2, updated today & chrome 27

Changed May 10, 2013 03:39PM UTC by dmethvin comment:2

cc: → jaubourg
component: unfiledajax
priority: undecidedlow

I didn't think XHR ever uses anything but UTF-8 for its entity body when a string is passed. See the spec:

Julian, what is your take?

Attempting to use anything other than UTF-8 nowadays is just masochism IMO.

Changed May 10, 2013 03:50PM UTC by timmywil comment:3

It does seem to be getting set in $.ajax.

Changed May 10, 2013 05:17PM UTC by timmywil comment:4

status: newopen

Changed May 10, 2013 05:46PM UTC by Markus.Staab comment:5

Sure utf-8 would be best to use, but in our legacy app we are not using utf8 yet and therefore need a different content type here..

Changed May 10, 2013 05:56PM UTC by jaubourg comment:6

resolution: → notabug
status: openclosed

Please read carefully.

So, regarding data that is a string:

Let encoding be "UTF-8".


Let mime type be "text/plain;charset=UTF-8".


Let the request entity body be data converted to Unicode and encoded as utf-8.

Which means the encoding is always UTF-8. Furthermore:

If a Content-Type header is in author request headers and its value is a valid MIME type that has a charset parameter whose value is not a case-insensitive match for encoding, and encoding is not null, set all the charset parameters of that Content-Type header to encoding.

Since encoding is UTF-8, the Content-Type header is modified to make sure it carries the proper encoding if needs be.

Nothing we can do to work around this in jQuery.

Changed May 13, 2013 07:27AM UTC by Markus.Staab comment:7

So, regarding data that is a string

data isn't a string in my example?

Changed May 13, 2013 08:52AM UTC by jaubourg comment:8

data isn't a string in my example?

The spec talks about data provided to the native XHR, not data provided to ajax. The latter *is* serialized as a string before being fed to the native XHR. Even if we used FormData, it would still get forced-encoding to UTF-8, as per the spec.

If you send data to the server, it will be encoded as UTF-8 and the corresponding Content-Type header will be modified accordingly. Again, there's nothing jQuery can do here.

Changed May 13, 2013 09:56AM UTC by Markus.Staab comment:9

Ok, so I will convert the data for those AJAX Request into my Apps encoding on the server side.

Thanks for your time!

Changed May 13, 2013 09:58AM UTC by Markus.Staab comment:10

maybe this could be made more clear in the docs to prevent similar questions in the future:

"contentType" parameter description on