Wildfly + JSF2 + Encoding Problem

Hallo,

ich habe ein interessantes Problem.

Ich habe eine xhtml-Seite:

[xml]<?xml version="1.0" encoding="UTF-8"?>

... ... ... ... [/xml]

Das Ergebnis ist:

Request URL:http://localhost:8080/larmic-ts-web/pages/security/userSettings.jsf
Request Method:POST
Status Code:200 OK
Request Headersview source
Accept:*/*
Accept-Encoding:gzip,deflate,sdch
Accept-Language:de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4
Connection:keep-alive
Content-Length:428
Content-type:application/x-www-form-urlencoded;charset=UTF-8
Cookie:JSESSIONID=PTRndBQsyJCPB5P7-LRqJ7S4
Faces-Request:partial/ajax
Host:localhost:8080
Origin:http://localhost:8080
Referer:http://localhost:8080/larmic-ts-web/pages/security/userSettings.jsf
User-Agent:Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.76 Safari/537.36
Form Dataview sourceview URL encoded
form:form
j_idt66-j_idt67-j_idt69-input:Lars
j_idt66-j_idt67-j_idt70-input:öäü
j_idt66-j_idt73-input:4
javax.faces.ViewState:2098127802059947657:6001803894589835595
javax.faces.source:j_idt66-saveBtn
javax.faces.partial.event:click
javax.faces.partial.execute:j_idt66-saveBtn form
javax.faces.partial.render:form
javax.faces.behavior.event:action
AJAX:EVENTS_COUNT:1
rfExt:null
javax.faces.partial.ajax:true
Response Headersview source
Cache-Control:no-cache
Connection:keep-alive
Content-Length:5065
Content-Type:text/xml;charset=UTF-8

Lasse ich das <f:ajax … /> weg, bekomme ich folgendes.

Request URL:http://localhost:8080/larmic-ts-web/pages/security/userSettings.jsf
Request Method:POST
Status Code:200 OK
Request Headersview source
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip,deflate,sdch
Accept-Language:de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4
Cache-Control:max-age=0
Connection:keep-alive
Content-Length:209
Content-Type:application/x-www-form-urlencoded
Cookie:JSESSIONID=IQaYd_hlBCME2ArugvYO6VSg
Host:localhost:8080
Origin:http://localhost:8080
Referer:http://localhost:8080/larmic-ts-web/pages/security/userSettings.jsf
User-Agent:Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.76 Safari/537.36
Form Dataview sourceview URL encoded
form:form
j_idt66-saveBtn:Speichern
j_idt66-j_idt67-j_idt69-input:Lars
j_idt66-j_idt67-j_idt70-input:üäö
j_idt66-j_idt73-input:4
javax.faces.ViewState:-8610282796613318591:-6948488830185753880
Response Headersview source
Connection:keep-alive
Content-Type:text/html;charset=UTF-8
Transfer-Encoding:chunked

Wie man hier sehen kann, fehlt beim Request im Content-Type das UTF-8, was dann falsch in die Bean übertragen wird.

Mich interessiert:

[ul]
[li] Warum funktioniert es mit AJAX?
[/li][li] Warum funktioniert es nicht ohne AJAX?
[/li][/ul]

Ich habe es bereits mit einem Encoding-Filter ausprobiert, was keine Hilfe brachte, da ich das Encoding im Wildfly hier nicht ändern kann. Ist das ein Bug des Servers?

Gruß und Dank

Mit Ajax werden die Postdaten von einem Javascript erzeugt, dass offensichtlich so gut codiert ist, dass hier UTF8 verwendet wird. Ohne AJAX werden die Postdaten direkt vom Browser erzeugt. Der ist recht frei in der Wahl der Charsets. Du kannst ihn aber überreden, indem Du für das -Element das Attribut “accept-charset” setzt. Details dazu findest du hier: http://www.w3schools.com/tags/att_form_accept_charset.asp
Wie Du das mittels JSF-Tags bewerkstelligst, weiß ich allerdings nicht.

probier mal für dein form das hier

<h:form acceptcharset="UTF-8">

oder generell für die Seite das hier

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

Das habe ich bereits getan. Das hilft allerdings nicht. Ich habe das Gefühl, dass der Undertow im Wildfly noch Probleme bereitet.

Welches Encoding über die Leitung geht, bekommst du am einfachsten mit wireshark heraus. Vielleicht hilft das ja, das Problem einzugrenzen.

Danke, das Encoding geht verloren, wie oben beschrieben. Die Frage ist nur, warum. :slight_smile:

Naja, Wildfly final soll ja kommen.

Danke euch!

Nachdem ich Wildfly 8.0.0.Final verwende, ist das Problem behoben. Schien also ein Bug zu sein.