3

I have ISO-8859-1 database, so I like to exchange requests entirely in this codepage. So, how to set content-type for AJAX requests in the right way?

Thevs
  • 3,189
  • 2
  • 20
  • 32
  • You're asking for trouble down the road. UTF-8 end-to-end or die! – Diodeus - James MacFarlane Aug 10 '12 at 18:07
  • 1
    possible duplicate of [How to change ajax-charset?](http://stackoverflow.com/questions/8285936/how-to-change-ajax-charset) – Diodeus - James MacFarlane Aug 10 '12 at 18:08
  • Yes, I actually can convert it when it comes to the server. But I want it in the "right" way. – Thevs Aug 10 '12 at 18:48
  • possible duplicate of [jQuery AJAX Character Encoding Problem](http://stackoverflow.com/questions/553463/jquery-ajax-character-encoding-problem) – Jürgen Thelen Aug 10 '12 at 22:01
  • I appreciate a comment added when downvoting. – Thevs Jul 14 '13 at 12:29
  • Actually I have non-UTF (one byte) database in the backend, so the question remains very important. – Thevs Jul 14 '13 at 12:30
  • 3
    @Thevs this is exactly the wrong way, you are trusting the client to send data in certain encoding but they can in fact send arbitrary data to your server. A robust server will check the encoding for validity and do conversion or reject. – Esailija Jul 16 '13 at 20:50
  • @Esailija: "but they can in fact send arbitrary data to your server" - no, they can't. – Thevs Jul 17 '13 at 13:18
  • 1
    Also, - what encoding has to do with data sent unchecked to the server?! – Thevs Jul 17 '13 at 13:21
  • @Thevs well what is preventing them? If a browser can connect to your server and send well-formed data, what is going to prevent someone from sending anything they want? – Esailija Jul 17 '13 at 13:47
  • @Esailija: Browser app has an unique session number. This is checked on the server side. – Thevs Jul 18 '13 at 12:35
  • 1
    That was a rhetorical question, there is absolutely no way your server can know whether a client is a normal user with a browser or someone using tools that can more easily send any data to server. You cannot trust the client even if you're a game server using proprietary protocols let alone an open one like HTTP. – Esailija Jul 18 '13 at 13:38
  • 3
    Stop please talking about SQL injections and (probably) PHP. I have non-SQL database and don't use PHP. My question is not about sanitizing input. – Thevs Jul 19 '13 at 11:07
  • 3
    What a people!? I know about all these issues, but I asked completely different question. – Thevs Sep 26 '13 at 19:22
  • 2
    thgis is old but for anyone stumbling on this, use the *.overrideMimeType('text/plain; charset=ISO-8859-1');* method of the xmlhttprequest object from [MDN Using XMLHttpRequest](https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Using_XMLHttpRequest) – Nikos M. Feb 11 '15 at 12:58

3 Answers3

4

Even though it's bad to do (bunch of comments above), this would work:

var xhr = new XMLHttpRequest(); 
xhr.open("GET", path, false);
xhr.setRequestHeader('Content-type', 'application/x-www-form-urlencoded; charset=ISO-8859-1')

If you are using jQuery: https://stackoverflow.com/a/553572/2527433

Community
  • 1
  • 1
Hieu Nguyen
  • 8,563
  • 2
  • 36
  • 43
  • Oops, typo, fixed now. – Hieu Nguyen Jul 20 '13 at 11:27
  • The `charset` parameter is illegal for this content type and some servers even reject requests as malformed if they do. It also makes no sense as valid content in this content-type uses only ASCII. – Esailija Jul 20 '13 at 14:14
  • Sending the charset along with application/ is not recommended. Lots of APIs are NOT accepting multiple settings in `Content-type` header. – Krasimir Oct 26 '15 at 15:35
1

According to the W3C spec for XMLHttpRequest.send(), the charset will end up being UTF-8 in almost all cases, depending on the value of data. Even any charset encoding you specify will likely be overwritten with UTF-8:

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.

There is some wiggle-room for the User Agent to determine the encoding: set the AJAX-containing page's encoding to ISO-8859-1. The UA will then assume ISO for all form submission (unless the form otherwise specifies a different encoding) and likely AJAX submission, depending on interpretation of the W3C algorithm.

Ultimately, the only reliable solution is to set the page the visitor sees (with the AJAX on it) to ISO-8859-1, and then make sure to check it and convert to ISO on the back-end (you need to be sanitizing all user input before sending it to the database anyway, so just add this conversion to the process). There are plenty of library functions to do this in PHP or your given language. There's no way to guarantee conformance with the specs otherwise, so absolutely check/ensure the encoding on the back-end.

Jay Dansand
  • 789
  • 1
  • 9
  • 13
0

I think I need to explain encoding and the charset parameter. These concern how the raw bytes sent over the network should be decoded.

For example, consider the content type application/x-www-form-urlencoded and the following data:

0x61253344254345254232

Because there was no charset (in fact, charset is illegal parameter for this content type...) ISO-8859-1 must be assumed. So decoding the above in ISO-8859-1 results:

"a%3D%CE%B2"

Now there is another format to decode (form urlencoded) which has its own rules. The current specs say that the percent encoding here must be UTF-8, so after doing string -> string transformation you get from the above:

"a=ß"

So as you can see, the format never uses characters other than ASCII so the charset doesn't really matter and is not supported anyway.

Your actual problem is unrelated to what encoding the percent encoding uses. Even if you defined a custom function that percent-encodes in ISO-8859-1, the server would still have to decode it on arrival and encode it for the database. You have nothing to gain from this.

Esailija
  • 138,174
  • 23
  • 272
  • 326