Bug Tracker

Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#13880 closed bug (notabug)

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 see http://jsfiddle.net/Q9vek/

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.

Change History (10)

comment:1 Changed 10 years ago by Markus.Staab

Tested on FF22a2, updated today & chrome 27

comment:2 Changed 10 years ago by dmethvin

Cc: jaubourg added
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: http://www.w3.org/TR/XMLHttpRequest/#the-send()-method

Julian, what is your take?

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

comment:3 Changed 10 years ago by timmywil

It does seem to be getting set in $.ajax. http://jsfiddle.net/timmywil/Q9vek/2/

comment:4 Changed 10 years ago by timmywil

Status: newopen

comment:5 Changed 10 years ago by Markus.Staab

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..

comment:6 in reply to:  5 Changed 10 years ago by jaubourg

Resolution: notabug
Status: openclosed

Please read https://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#the-send()-method 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.

comment:7 Changed 10 years ago by Markus.Staab

So, regarding data that is a string

data isn't a string in my example?

comment:8 in reply to:  7 Changed 10 years ago by jaubourg

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.

comment:9 Changed 10 years ago by Markus.Staab

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

Thanks for your time!

comment:10 Changed 10 years ago by Markus.Staab

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

"contentType" parameter description on http://api.jquery.com/jQuery.ajax/

Note: See TracTickets for help on using tickets.