Maybe it is a bug in class CoyoteRequest, my solution is here: diff -u CoyoteRequest.java.old CoyoteRequest.java.new --- CoyoteRequest.java.old 2003-12-09 21:51:57.000000000 +0800 +++ CoyoteRequest.java.new 2003-12-09 21:52:23.000000000 +0800 @@ -2325,9 +2325,9 @@ String enc = coyoteRequest.getCharacterEncoding(); if (enc != null) { - parameters.setEncoding(enc); + parameters.setQueryStringEncoding(enc); } else { - parameters.setEncoding + parameters.setQueryStringEncoding (org.apache.coyote.Constants.DEFAULT_CHARACTER_ENCODING); }
Thanks, we were not aware of that "bug" ;-) IMO, you should look into tomcat-dev's archives for the full details. BTW, in your patch, you should leave the setEncoding method call, also (it's useful for the POST body, if any). I sort of changed my mind on the subject, and I could be talked into adding a "compatibility" boolean flag to the connector, if the default stays to using a separate encoding for the URI parameters.
Thanks for your reminding. I have reviewed the code. The parameters.setQueryStringEncoding method and the parameters.handleQueryParameters method handle the parameters in the encoded uri at both "get" and "post" method. Specially if the contentType equals "application/x-www-form-urlencoded" (the default encoding for all forms), it should deal with the parameters in the post body. The setEncoding method must be called before calling "parameters.processParameters(formData, 0, len)" method, otherwise you can call parameters.processParameters(formData, 0, len, enc)" directly.
Created attachment 9480 [details] diff -u