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: |
Description
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.
Attachments (0)
Change History (10)
Changed May 10, 2013 01:57PM UTC by comment:1
Changed May 10, 2013 03:39PM UTC by comment:2
| cc: | → jaubourg |
|---|---|
| component: | unfiled → ajax |
| priority: | undecided → low |
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.
Changed May 10, 2013 03:50PM UTC by comment:3
It does seem to be getting set in $.ajax. http://jsfiddle.net/timmywil/Q9vek/2/
Changed May 10, 2013 05:17PM UTC by comment:4
| status: | new → open |
|---|
Changed May 10, 2013 05:46PM UTC by 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 comment:6
| resolution: | → notabug |
|---|---|
| status: | open → closed |
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.
Changed May 13, 2013 07:27AM UTC by 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 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 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 comment:10
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/
Tested on FF22a2, updated today & chrome 27