I've upgraded from rich faces 3.3 to rich faces 4.2 because ajax didn't work for IE9. Now it still not works.
After receiving the Response IE gets an JS error "SCRIPT58734: Der Vorgang konnte aufgrund des folgenden Fehlers nicht fortgesetzt werden: c00ce56e." while trying
data.responseText=request.responseText
on jsf.js.html?ln=javax.faces&conversationContext=2, Line 1 Row 21747
I think it's because of an incorrecct HTTP header
Content-Type: text/xml;charset=UTF8
should be
Content-Type: text/xml;charset=UTF-8
Here The raw-response of the server
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-Powered-By: JSF/2.0
Cache-Control: no-cache
Content-Type: text/xml;charset=UTF8
Content-Length: 293
Date: Tue, 17 Apr 2012 15:25:22 GMT
<?xml version='1.0' encoding='UTF8'?>
<partial-response><changes><update id="outtest"><![CDATA[<span id="outtest"><span class="outhello">Hello !</span></span>]]></update><update id="javax.faces.ViewState"><![CDATA[2809980525147413088:295565165947012503]]></update></changes></partial-response>
i'm usinng
javaee-web-api 6
myfaces-orchestra-core 1.4
Hibernate 4.1
Spring 3.1.1
Richfaces 4.2.0
Primefaces 3.2
jsf-api+impl 2.1.7
jstl 1.2
and running on tomcat 7
EDIT: of now i'm sure its the header. I set a breakpoint in charles-proxy and edited the response header manually, with the edited http header IE9 showed the right result without any errors
Your analysis is correct. The charset
attribute in the Content-Type
header is wrong and IE9 chokes on that with error c00ce56e
.
JSF uses by default the one as obtained from ServletRequest#getCharacterEncoding()
. This normally defaults to the client-specified one, or null
if there's none (which is often the case). This is normally overrideable by some custom filter which calls request.setCharacterEncoding()
.
Given the incorrect charset, this can only mean that your web application is somewhere calling request.setCharacterEncoding()
with "UTF8"
instead of "UTF-8"
.
I'd start checking all filters and their configuration.