Could not complete the operation due to error c00ce56e

Question

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

Answer 1

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.

Answer 2

i got similar error but the problem was with the response headers content length. We had 24kb of data on the request header and we have to reduce it to half. That fixed the issue. i hope this helps someone.