Hide Forgot
Description of problem: See the description of the bug [1]. The bug is marked as fixed, but I am able to reproduce it using the bundled jsf (2.1.19) and the latest 2.1.26, even on clean Tomcat, so it is not fixed at all. The encoding in a request is not set properly (is set to null) and thus JBoss defaults to its default encoding (ISO-8859-1 I believe). Note: This issue doesn't appear always. Its usually there right after deploy, or when a new user accesses the view. On Tomcat, however, the issue is reproducible on every submit. [1] https://java.net/jira/browse/JAVASERVERFACES-2217 Steps to Reproduce: The same as in the JIRA 1. Get the reproducer from the JIRA. 2. Deploy and open the reproducer. 3. Enter some international characters, like "ěšščřčřžžýáíéá" and submit. 4. See the submited string is corrupted.
Created attachment 803400 [details] Reproducer from JIRA
This bug can still be reproduced in EAP 6.3.0.ER10.
Note that a filter can be created to work around this problem, as described in the customer case: https://access.redhat.com/support/cases/00938808/#a0aA000000AHghHIAT
Moving this issue to the Web component. Note that JAVASERVERFACES-2217 was marked as fixed by the Mojarra team because adding the following configuration to glassfish-web.xml fixes the problem: <parameter-encoding default-charset="UTF-8"/> (The above configuration is described here: http://docs.oracle.com/cd/E18930_01/html/821-2417/beavn.html) Does JBoss Web have anything equivalent to this configuration?
URI encoding is not portable. Both Tomcat and web default to ISO-8859-1 in most versions, and have URI encoding configuration. Use the org.apache.catalina.connector.URI_ENCODING system property in web.
This issue pertains to request parameters from form data, not from query string, so I think it still is a valid issue. WDYT, Remy?
It is not possible this issue is valid then. Both Tomcat and web will correctly process the parameters encoding in the request body according to the encoding specified in content-type.
In that case, I guess it's not an issue of JBoss Web but there's still some issue in JSF integration (or something else). The issue is still consistently reproducible using the steps in the description.
I misunderstood this issue, but it is an enhancement if it is about web. The default for the request body if no encoding is specified in the content-type is always ISO-8859-1, that comes from the HTTP spec. The grey area only involves the URI encoding (both the path and query string portion), which is why I thought this would be related to that. I find it difficult to believe there's an issue remaining in that JSF impl which causes the absence of charset and that would always occur in Tomcat, this would have been repeatedly reported IMO. So there are two options you should decide on: - it's a JSF issue since the request sent in incorrect (it should specify a charset in its content-type unless it is ISO-8859-1) - web and Tomcat should have a configuration option to allow setting the default encoding, but it's probably not very useful (it would be less likely it matches the client encoding since it is rather well known, and it was never actually requested before)
The second option might be worth considering. Undertow provides a setting to override the default encoding (see https://issues.jboss.org/browse/UNDERTOW-136 and https://issues.jboss.org/browse/WFLY-2533). With this setting, this issue doesn't occur on WildFly.