11

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

700 Software
  • 85,281
  • 83
  • 234
  • 341
wutzebaer
  • 14,365
  • 19
  • 99
  • 170

2 Answers2

18

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.

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • ok t hhought of a filter too. i think i'll add an response filter wich fixes the header as an termporary fix until i find the filter which causes this error. thanks – wutzebaer Apr 18 '12 at 05:42
  • i second that.. i had exactly same problem when i had charset cp-1251 instead of windows-1251 - so keep an eye on your encoding! – Alex K Aug 16 '12 at 12:53
  • 1
    Thanks thanks thanks! My fix was adding charset: `Response.ContentType = "application/json;charset=utf-8";` – iambriansreed Jan 28 '13 at 23:07
  • Apparently this will happen for any async loaded URL, if it has an invalid charset. In my case it was a couple of .html-templates for Angular and a fallback charset of "utf8" on the web server that triggered the error. I'll never forget the dash again ;-) – Saustrup Jul 02 '14 at 09:24
0

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.

ckalyanp
  • 1