We ran into an issue where some user tried entering Danish character ø in his first name and it was not updating properly in LDAP. First we thought its a LDAP issue but then I found that in some other page where we use DWR api the same character is getting updated in LDAP properly. Finally we nailed it down to Tomcat/Spring where even after doing
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
the character encoding was not properly set on request.
Adding this filter solved the issue. This has to be first filter in web.xml,
otherwise it wont work, I had it earlier as the second filter and i wasted some time debugging it
<filter> <!-- Filter to handle content encoding for UTF-8 encoding, this has to be the FIRST FILTER, do not move --> <filter-name>encodingFilter</filter-name>
<filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class> <init-param> <param-name>encoding</param-name> <param-value>UTF-8</param-value> </init-param> <init-param> <param-name>forceEncoding</param-name> <param-value>true</param-value> </init-param> </filter> <filter-mapping> <filter-name>encodingFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>
Technically all its doing is
request.setCharacterEncoding("UTF-8"); response.setCharacterEncoding("UTF-8");
Ideally this should be set by tomcat as I had the below set,
but its not working somehow so setting this filter made it work.
DWR was parsing the request body manually and thats why it was working and spring was not.
<Connector port="8080" URIEncoding="UTF-8" ......>
Yeah, this is a familiar tale ... we do the exact same thing in our webapp. Originally it lived in a struts RequestProcessor, then as we introduced Jersey & other stuff we wrote our own filter to make the aforementioned request/response encoding calls across the board.
ReplyDelete