Affects Version/s: 2.0.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.6, 2.1, 2.1.0, 2.1.1, 2.1.2, 2.1.3
Fix Version/s: None
We have a general problem with the encoding situated somewhere between spec leak and implementation.
Currently the encoding of an ajax request has a content-type: charset=utf-8
While this is a valid header this might cause problems in non utf situations.
The problem simply is once you have a page with another enconding you might run into the usual coding hell of savestating the input in the wrong encoding type.
I investigated into the issue and found following out:
a) Character encoding can easily be detected on the clientside without any additional server code
b) We can change the request header accordingly, this needs patches on both implementations Mojarra and MyFaces, but they should be minimal.
c) All browsers except Firefox pick that up properly, this is a big issue and a bugreport from my side has been filed on the Firefox side.
d) The response then comes properly in the encoding given by the original page (response header is set properly)
e) The encoding of the response xml is marked properly in the encoding of the request in Mojarra, Mojarra behaves properly there. MyFaces has an issue there by always sending the response content type in the partial response writer in UTF-8.
A bug on the myfaces side has been filed on that one:
So the question now is in which direction to go.
Firefox has a problem, but does this really affect us. Since we nailed down the encoding incorrectly until now clientside to utf-8 and not to many users were affected, we probably can fix the issue without giving to many problems for firefox users. The downside is we would break backwards compatibility.
If we make this behavior default off and add a config param one way or the other, we would be backwards
compatible but would introduce yet another parameter.
So the problem really comes down to the issue of:
a) Do we autodetect and then set the encoding properly (would work
without spec change probably but would mean that we break backwards compatibility minimally)
b) Do we ignore it and stay where we are (in my opinion a no go)
c) Do we introduce an artificial charset param which would mean a spec extension