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
>
>

Reply via email to