tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Problem with Transfer-Encoding
Date Sat, 05 Jul 2014 15:38:34 GMT
Konstantin Kolinko wrote:
> 2014-07-05 9:24 GMT+04:00 Sushil Prusty <>:
>> 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
>> 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.

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:
For additional commands, e-mail:

View raw message