Home/ Questions/Q 7796869
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-01T23:30:13+00:00

I’ve upgraded from rich faces 3.3 to rich faces 4.2 because ajax didn’t work

  • 0

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

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0