Dear User Thanks for you input. I just debugged using HttpFox here is below you find header
(Request-Line) POST /test/testUserEditAction.do?dojoIframeSend=true HTTP/1.1 Host ********** User-Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:30.0) Gecko/20100101 Firefox/30.0 Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language en-US,en;q=0.5 Accept-Encoding gzip, deflate Referer https://s ************Action.do?action=login&flashVersion=9.0.47.0&hasCorrectFlashVersion=false&product=xyz Cookie JSESSIONID=******************; doNotShowStartupOnLoad=true Connection keep-alive Content-Type multipart/form-data; boundary=---------------------------******************* Content-Length 4039 In Post body -----------------------------1550434539176507601876254213 Content-Disposition: form-data; name="disclaimerText" ZażóÅÄ gÄÅlÄ jaźÅ! ta funkcjonalnoÅÄ nie jest wspierana -----------------------------1550434539176507601876254213 I believe psot data got changed before reaching to server . Do you have any ideas what's wrong here, where the error might be ? On Sat, Jul 5, 2014 at 9:08 PM, André Warnier <a...@ice-sa.com> wrote: > Konstantin Kolinko wrote: > >> 2014-07-05 9:24 GMT+04:00 Sushil Prusty <sushil.pru...@gmail.com>: >> >>> Hello, >>> >>> summary of my Problem: >>> >>> When a client POSTs Tranfer-Encoding data using browser , >>> my server is not processing the request character encoding properly . >>> >>> >>> I send the following request: >>> Content-Type text/html;charset=UTF-8 >>> Date Sat, 05 Jul 2014 05:10:09 GMT >>> Server Apache-Coyote/1.1 >>> Transfer-Encoding chunked >>> *disclaimerTextZażółć gęślą jaźń! ta funkcjonalność nie jest wspierana* >>> >>> Full details: >>> >>> My application running on apache-tomcat-7.0.40 >>> and Java >>> 1.6.x) in linux box. >>> >>> Below response is changed once it's reach to my controller >>> *ZażóÅÄ gÄÅlÄ jaźÅ! ta funkcjonalnoÅÄ nie jest wspierana* >>> >>> I have below configuration in server.xml >>> >>> <Connector port="80" protocol="HTTP/1.1" connectionTimeout="20000" >>> maxPostSize="5242880" maxParameterCount="25000"/> >>> <Connector >>> port="443" >>> protocol="HTTP/1.1" >>> scheme="https" >>> noCompressionUserAgents="gozilla, traviata" >>> >>> compressableMimeType="text/html,text/xml,text/javascript, >>> text/css,application/javascript,application/json" >>> URIEncoding="UTF-8" >>> /> >>> and in my catalina.sh >>> set JAVA_OPTS=-Djavax.servlet.request.encoding=UTF-8 >>> -Dfile.encoding=UTF-8 >>> (...) >>> >> >> As a sanity check: >> 1) That "I send the following request" listing looks more like a >> response, not a request. (E.g. the "Server Apache-Coyote/1.1" header >> makes no sense in a request). >> >> So you are lying somewhere. >> >> There is no point for me to try guessing what you are doing. You may >> have confused "reading" with "writing" somewhere, and without source >> code one cannot verify your words. >> >> You have to provide a step-by-step instruction and enough source code >> so that a person who is not familiar with your system were able to >> reproduce your problem. >> >> >> 2) Content-Type says "text/html", but that line of text is not a valid >> HTML document. >> >> > +1 > Character encoding/decoding issues are hell to debug as it is, because > they are like quantum physics : even looking at them can change them.(*) > So you need to provide *accurate* and "raw" information, otherwise it is > just a loss of time for everyone. > > Use a browser plugin like HttpFox, LiveHttpHeaders, HttpFox or similar to > monitor the requests being sent and responses being received, at the > browser level. All these plugins allow you to selectively dump > requests/responses to a file. Do that. > Also, check in your browser that when you receive a response page back > from the server, your browser is really seeing this response in the proper > character set (use "View.. Character encoding.."). > > "Transfer Encoding" has nothing to do with the *character encoding* of > either the request or the response. The little imprecise data that the OP > provided above /suggests/ that there is some double encoding taking place > /somewhere/, but so far it could as well be in the email client that he > used to post to the list, as anywhere else. > > (*) with the wrong editor, or the wrong locale e.g. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >