1 Reply Latest reply on Jun 4, 2019 8:23 AM by jaikiran

    ISSUE: WILDFLY AJP doesn't correctly take into account the encoding charset specified in ContentType inside the request header

    kadelcastillo

      Hello,

       

      We migrated from JBOSS to WILDFLY and currently encountered an encoding error.

      Our application makes use of the charset defined in the ContentType of Request Header to read the encoded parameters on a URL query string. However with WILDFLY, it defaults to UTF-8, which is the default value assigned to the Url-charset attribute.

       

       

      Test Case 1: (FAILED)

      WildFly Url Charset: UTF-8

      Sample Query String: ?VAL=XXXXX&SELECT=CODE%3D%D6%D9%D1&MAX=10

      Sample Request Header:

      Connection: keep-alive

      User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; InfoPath.1)

      Content-Type: application/x-www-form-url-encoded;charset=ISO-8859-1

      Host: samplehostname.host.com:8080

      Sample code:

      1. String select = req.getParameter("SELECT"); 
      2. System.out.println("SELECT( expected:CODE=ÖÙÑ ) : " + select); 

       

      Result:

      SELECT( expected:CODE=ÖÙÑ ) : CODE=���

       

       

      Test Case 2: (PASSED)

      WildFly Url Charset: UTF-8

      Sample Query String: ?VAL=XXXXX&SELECT=CODE%3D%C3%96%C3%99%C3%91&MAX=10

      Sample Request Header:

      Connection: keep-alive

      User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; InfoPath.1)

      Content-Type: application/x-www-form-url-encoded;charset=UTF-8

      Host: samplehostname.host.com:8080

      Sample code:

      1. String select = req.getParameter("SELECT"); 
      2. System.out.println("SELECT( expected:CODE=ÖÙÑ ) : " + select); 

       

      Result:

      SELECT( expected:CODE=ÖÙÑ ) : CODE=ÖÙÑ

       

       

       

      We tried using HttpServletRequest#setCharacterEncoding and while it returned the charset we assigned when called HttpServletRequest#getCharacterEncoding,  HttpServletRequest#getParameter still decodes the query string to what the value assigned to Url-charset attribute.

       

      Test Case 3: (FAILED)

      WildFly Url Charset: UTF-8

      Sample Query String: ?VAL=XXXXX&SELECT=CODE%3D%D6%D9%D1&MAX=10

      Sample Request Header:

      Connection: keep-alive

      User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; InfoPath.1)

      Content-Type: application/x-www-form-url-encoded;charset=ISO-8859-1

      Host: samplehostname.host.com:8080

      Sample code:

      req.setCharacterEncoding("ISO-8859-1");  
      String select = req.getParameter("SELECT");  
      System.out.println("Character Encoding: "+req.getCharacterEncoding());
      System.out.println("SELECT( expected:CODE=ÖÙÑ ) : " + select);  

       

      Result:

      Character Encoding: ISO-8859-1

      SELECT( expected:CODE=ÖÙÑ ) : CODE=���

       

       

      We also tried changing the value of the [Url-charset] attribute inside AJP configurations but this only hardcodes and set it to a single charset. We wish to have the charset read first from the ContentType Request Header before reading the default charset defined in the [Url-charset] attribute. In JBOSS, org.apache.catalina.connector.USE_BODY_ENCODING_FOR_QUERY_STRING or useBodyEncodingForURI attribute is what we used to toggle ON/OFF if the encoding charset specified in the ContentType should be used for decoding query parameters instead of using the value assigned to URIEncoding. Is there an equivalent attribute for this in WILDFLY?

       

      We are also currently using WILDFLY 8.2 version. I'm wondering if this already fixed in the later versions? I read the latest Untertow source code a bit and it seems the codes regarding AJP (AjpOpenListener, AjpRequestListener, AjpRequestParser etc) still uses URI-charset as default and does not consider other ways of setting the charset.

       

      We're hoping you can assist us on this.

       

      Thanks,

      Korina