You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Saurav Maulick <sa...@gmail.com> on 2015/10/05 18:23:06 UTC
Tomcat bad char issue with new cluster
Hi All,
I know Tomcat 5.5 is very old and this is outdated, but we are still using
Tomcat 5.5 and we got an issue. Please help.
Problem description:
Recently my client has asked me to add two new clusters in the production,
after adding the clusters we found that these two new clusters are not able
to handle special characters.
When user copies some data (especially from MS-Word which contains double
quote) and paste into the application we have found that double quote
becomes junk character, but these problems only persist with newly created
clusters not with old clusters.
While creating the new cluster I just copied the old cluster folder and all
the clusters are identical except some changes in server.xml.
Could you please help me to resolve this issue?
NB. UTF-8 char encoding present in the xml files
--
Thanks and Regards,
Saurav
Re: Tomcat bad char issue with new cluster
Posted by Saurav Maulick <sa...@gmail.com>.
No Mikel we don't have any filter in conf/web.xml.
On Tue, Oct 6, 2015 at 3:14 PM, Mikel Ibiricu <jl...@gmail.com> wrote:
> Do you have any filter defined in conf/web.xml in the old ones which run
> properly?
>
> Regards,
> Mikel
> El 06/10/2015 15:37, "Saurav Maulick" <sa...@gmail.com> escribió:
>
> > Hi Christopher,
> >
> >
> > Please find my answer below
> >
> >
> > *Two new clusters or two new nodes added to an existing cluster?*
> >
> > Two Nodes
> >
> >
> > *What is the difference between the conf/server.xml on a "working" server
> > and one of these new servers that is misbehaving?*
> >
> > No difference. Apart from Server port –Configuration, non-SSL
> > HTTP/1.1Connector port Configuration, AJP 1.3 Connector port
> Configuration,
> > and jvmRoute Configuration
> >
> >
> > *Identical WAR files deployed to all servers?*
> >
> > Yes all the nodes have identical WAR file
> >
> >
> > On Mon, Oct 5, 2015 at 9:06 PM, Christopher Schultz <
> > chris@christopherschultz.net> wrote:
> >
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA256
> > >
> > > Saurav,
> > >
> > > On 10/5/15 12:23 PM, Saurav Maulick wrote:
> > > > I know Tomcat 5.5 is very old and this is outdated, but we are
> > > > still using Tomcat 5.5 and we got an issue. Please help.
> > > >
> > > > Problem description:
> > > >
> > > > Recently my client has asked me to add two new clusters in the
> > > > production, after adding the clusters we found that these two new
> > > > clusters are not able to handle special characters.
> > >
> > > Two new clusters, or two new nodes added to an existing cluster?
> > >
> > > > When user copies some data (especially from MS-Word which contains
> > > > double quote) and paste into the application we have found that
> > > > double quote becomes junk character, but these problems only
> > > > persist with newly created clusters not with old clusters.
> > > >
> > > > While creating the new cluster I just copied the old cluster folder
> > > > and all the clusters are identical except some changes in
> > > > server.xml.
> > > >
> > > > Could you please help me to resolve this issue?
> > > >
> > > > NB. UTF-8 char encoding present in the xml files
> > >
> > > What is the difference between the conf/server.xml on a "working"
> > > server and one of these new servers that is misbehaving? Identical WAR
> > > files deployed to all servers?
> > >
> > > - -chris
> > > -----BEGIN PGP SIGNATURE-----
> > > Comment: GPGTools - http://gpgtools.org
> > >
> > > iQIcBAEBCAAGBQJWEx6mAAoJEBzwKT+lPKRYPzIP/iFpPGH+zfPOsgwtqhnqe5ou
> > > 5PqaVEJ0G9+854Gs+q19n9Fcug2NHCnjRaDHj/ujhiOjj2phF1KbWtvEOmMeH6rG
> > > QpuPTPr6DJZiEZpnvCaK2tolQEwnO7CqJ1AEqQo/TQ7IzKFx+Ou5SxZ9m8kQeBKg
> > > ZrPt4vBxrASaELSn+vPPzsA2aBzr9OXijO35Gbjf09FCbR7BC/QnucbAaS6b3z2W
> > > jxrFDRzv7QTxSoA9c8QdNPdcJXEbLQF59yf/4JO/Bx68A7apneSWjo9zw9POWfD2
> > > wHysHZJFF8WBbh1lBJXFuyLMT9luu1v4I7nvdYU98S2p9EOqVTnDM84XBVN9xd/r
> > > TbNGvcIErLsXeNRqHaXSCF95KbjMSdeKCYKfroPz9/xEZUWWpdFRm6OLVTY6mF1F
> > > WDJZUltgGT/O6iM0x39rcEnwapX5XUlPgpolhhEJFC4PXZgLpwQQTwhEBACtClVn
> > > 30P4brBZYIW1NIR4Vq7yI0ltpf7CT0X3Y7xSvP53yM5zIpcmwQsWVCnle+8XY9bz
> > > 4msgAfpp5Xb2q3ovGwrCKahWCeddTofUfgqCBmg7fgvD7K7812rSgjOQ617QgNl5
> > > FZnt9Td79vcWe7I8J1vJdvWTymuydfVMWEu5ptOpORwsGdWVYI/qnOTCl+b8XW7K
> > > oVU1afvuvfBA+abbnz/L
> > > =e9Is
> > > -----END PGP SIGNATURE-----
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > > For additional commands, e-mail: users-help@tomcat.apache.org
> > >
> > >
> >
> >
> > --
> > Thanks and Regards,
> > Saurav
> >
>
--
Thanks and Regards,
Saurav
Re: Tomcat bad char issue with new cluster
Posted by Mikel Ibiricu <jl...@gmail.com>.
Do you have any filter defined in conf/web.xml in the old ones which run
properly?
Regards,
Mikel
El 06/10/2015 15:37, "Saurav Maulick" <sa...@gmail.com> escribió:
> Hi Christopher,
>
>
> Please find my answer below
>
>
> *Two new clusters or two new nodes added to an existing cluster?*
>
> Two Nodes
>
>
> *What is the difference between the conf/server.xml on a "working" server
> and one of these new servers that is misbehaving?*
>
> No difference. Apart from Server port –Configuration, non-SSL
> HTTP/1.1Connector port Configuration, AJP 1.3 Connector port Configuration,
> and jvmRoute Configuration
>
>
> *Identical WAR files deployed to all servers?*
>
> Yes all the nodes have identical WAR file
>
>
> On Mon, Oct 5, 2015 at 9:06 PM, Christopher Schultz <
> chris@christopherschultz.net> wrote:
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> >
> > Saurav,
> >
> > On 10/5/15 12:23 PM, Saurav Maulick wrote:
> > > I know Tomcat 5.5 is very old and this is outdated, but we are
> > > still using Tomcat 5.5 and we got an issue. Please help.
> > >
> > > Problem description:
> > >
> > > Recently my client has asked me to add two new clusters in the
> > > production, after adding the clusters we found that these two new
> > > clusters are not able to handle special characters.
> >
> > Two new clusters, or two new nodes added to an existing cluster?
> >
> > > When user copies some data (especially from MS-Word which contains
> > > double quote) and paste into the application we have found that
> > > double quote becomes junk character, but these problems only
> > > persist with newly created clusters not with old clusters.
> > >
> > > While creating the new cluster I just copied the old cluster folder
> > > and all the clusters are identical except some changes in
> > > server.xml.
> > >
> > > Could you please help me to resolve this issue?
> > >
> > > NB. UTF-8 char encoding present in the xml files
> >
> > What is the difference between the conf/server.xml on a "working"
> > server and one of these new servers that is misbehaving? Identical WAR
> > files deployed to all servers?
> >
> > - -chris
> > -----BEGIN PGP SIGNATURE-----
> > Comment: GPGTools - http://gpgtools.org
> >
> > iQIcBAEBCAAGBQJWEx6mAAoJEBzwKT+lPKRYPzIP/iFpPGH+zfPOsgwtqhnqe5ou
> > 5PqaVEJ0G9+854Gs+q19n9Fcug2NHCnjRaDHj/ujhiOjj2phF1KbWtvEOmMeH6rG
> > QpuPTPr6DJZiEZpnvCaK2tolQEwnO7CqJ1AEqQo/TQ7IzKFx+Ou5SxZ9m8kQeBKg
> > ZrPt4vBxrASaELSn+vPPzsA2aBzr9OXijO35Gbjf09FCbR7BC/QnucbAaS6b3z2W
> > jxrFDRzv7QTxSoA9c8QdNPdcJXEbLQF59yf/4JO/Bx68A7apneSWjo9zw9POWfD2
> > wHysHZJFF8WBbh1lBJXFuyLMT9luu1v4I7nvdYU98S2p9EOqVTnDM84XBVN9xd/r
> > TbNGvcIErLsXeNRqHaXSCF95KbjMSdeKCYKfroPz9/xEZUWWpdFRm6OLVTY6mF1F
> > WDJZUltgGT/O6iM0x39rcEnwapX5XUlPgpolhhEJFC4PXZgLpwQQTwhEBACtClVn
> > 30P4brBZYIW1NIR4Vq7yI0ltpf7CT0X3Y7xSvP53yM5zIpcmwQsWVCnle+8XY9bz
> > 4msgAfpp5Xb2q3ovGwrCKahWCeddTofUfgqCBmg7fgvD7K7812rSgjOQ617QgNl5
> > FZnt9Td79vcWe7I8J1vJdvWTymuydfVMWEu5ptOpORwsGdWVYI/qnOTCl+b8XW7K
> > oVU1afvuvfBA+abbnz/L
> > =e9Is
> > -----END PGP SIGNATURE-----
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
>
>
> --
> Thanks and Regards,
> Saurav
>
Re: Tomcat bad char issue with new cluster
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Saurav,
On 10/7/15 11:52 AM, Christopher Schultz wrote:
> Saurav,
>
> On 10/6/15 9:37 AM, Saurav Maulick wrote:
>> Please find my answer below
>
>
>> *Two new clusters or two new nodes added to an existing
>> cluster?*
>
>> Two Nodes
>
>
>> *What is the difference between the conf/server.xml on a
>> "working" server and one of these new servers that is
>> misbehaving?*
>
>> No difference. Apart from Server port –Configuration, non-SSL
>> HTTP/1.1Connector port Configuration, AJP 1.3 Connector port
>> Configuration, and jvmRoute Configuration
>
>
>> *Identical WAR files deployed to all servers?*
>
>> Yes all the nodes have identical WAR file
>
> The problem here is usually with the <Connector> URIEncoding
> setting (probably should be UTF-8 these days) or with clients who
> send a content-type header without specifying the character
> encoding, leaving the server to default to ISO-8851-1 (instead of
> UTF-8, which ought to be the default these days).
>
> Tomcat 8 uses UTF-8 as the default <Connector> URIEncoding, unless
> the system property org.apache.catalina.STRICT_SERVLET_COMPLIANCE
> is set to true. Tomcat 5.5 *always* uses ISO-8859-1 as the
> default. http://tomcat.apache.org/tomcat-8.0-doc/config/http.html
> http://tomcat.apache.org/tomcat-5.5-doc/config/http.html
>
> Mikel was asking about <filter> in Tomcat's conf/web.xml because
> it's typical these days to use a SetCharacterEncodingFilter to
> override the HTTP-spec-defined requirement that ISO-8859-1 be used
> when the client does not specify a character set.
> http://tomcat.apache.org/tomcat-8.0-doc/config/filter.html#Set_Charact
er
>
>
_Encoding_Filter
> http://tomcat.apache.org/tomcat-5.5-doc/config/filter.html#Set_Charact
er
>
>
_Encoding_Filter
>
> Finally, you should double-check your database connection
> configuration. If you have the character set incorrect, there, you
> can break data in both directions from the database.
>
> Can you tell if the characters are broken for GET vs POST
> requests? Can you check to see if this is an input or output
> problem? You can check the string in the database to see if the
> error is present there?
>
> Have a read through this document; it will help you look at all
> the places where there might be a problems:
> http://wiki.apache.org/tomcat/FAQ/CharacterEncoding#Q8
Also:
http://wiki.apache.org/tomcat/FAQ/CharacterEncoding#Q5
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJWFUDJAAoJEBzwKT+lPKRYlQMQAJxJaHq2X448+O0YBbzOhR+r
1eUTGgZzKpPmU+yvqXXuztxPf0fzQlck/juETnEaF+vnqncmcPmiFb8D+wLTwg0x
Zw62mRfy5rh4jRMHstU1QheeY2c0Bv0iewhqqdMP19uAgwStn95Oov9EBMKYmka2
2jkmw2jfyVzVYoosJo1AqQ04f0UNv2DOSYnQrh/XudpCHK2SGcXy8efn3upMO28q
5OJOlLCEMSPGyQv2W97AwfcG5cAZq+VJglyVGmz/rU3JrO1b3Gqc+sqtcjsJ0/kq
MlMn6WS9QNCgKbm/sMjsLD/wNZpWhx1IbyateT175JGS4z+VFOSDBfLNL9eUc+eC
k61b+slemyt3aRYysryKlP7GEgl+Kja9v9FxCzkxOrRs8RY8ymKe0HcFRvLarVwt
kYDE7ByKpAsyAPEBRYXE4TXuesc/KlC2eCHWBIFE/2/bznGf8vHjwCjcJSz3j8I9
nm6b4IAUSOHrXECBBdQ5Yzx3pKdCUo0I7TTF7JzkZ1md06JjJOMvUL5b2wFzIFIM
Tv3Nk2NI4iiHzU1nqr1QAoBdHVpC25/QfgoCtSSJPVA4/Y3rZ2oBQQPvr0DiDDR6
uc7zwApqiFXtP2onLkCSJJxL3YTkHoTrmRzSVgbGNw0pk6NhadxBqH5DV/Sn6PPX
y+M6jqRkfQ7lvH3bMxqq
=gsYD
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat bad char issue with new cluster
Posted by Saurav Maulick <sa...@gmail.com>.
Hi Christopher,
On Thu, Oct 8, 2015 at 5:11 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Saurav,
>
> On 10/8/15 4:45 PM, Saurav Maulick wrote:
> > URIEncoding setting is present in both the HTTP Connector and AJP
> > Connector.
>
> ... and what is the value of that attribute?
>
Please see the Connector Values
<!-- Define a non-SSL HTTP/1.1 Connector on port 8080 -->
<Connector port="8087" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" redirectPort="8443" acceptCount="100"
connectionTimeout="20000" disableUploadTimeout="true"
useBodyEncodingForURI="true" URIEncoding="UTF-8"/>
<!-- Define an AJP 1.3 Connector on port 8009 -->
<Connector port="8079"
enableLookups="false" redirectPort="8443" protocol="AJP/1.3"
useBodyEncodingForURI="true" URIEncoding="UTF-8"/>
>
> > <filter> is not present in the conf/web.xml.
>
> Where? The working or non-working nodes? Or both?
>
<filter> is not present in the both the working and non working nodes.
>
> The real question is "what is making the working nodes work". The
> you'll have the answer to the question "what do I need to do to my
> non-working nodes to make them work".
>
> It might end up being something simple like LC_CTYPE environment
> variable on one system versus the other. It *should not* be something
> like that -- there is configuration available everywhere for setting
> the character encoding of the data being handled, but things like
> database drivers might default to using the local default encoding.
>
> > when I try to add <filter> it gives HTTP Status 404" error (please
> > see the below <filter> code
> >
> > <filter>
> >
> > <filter-name>SetCharacterEncoding</filter-name>
> >
> >
> > <filter-class>org.apache.catalina.filters.SetCharacterEncodingFilter</
> filter-class>
> >
> > <init-param>
> >
> > <param-name>encoding</param-name>
> >
> > <param-value>UTF-8</param-value>
> >
> > </init-param>
> >
> > </filter>
> >
> >
> >
> > <filter-mapping>
> >
> > <filter-name>SetCharacterEncoding</filter-name>
> >
> > <url-pattern>/*</url-pattern>
> >
> > <url-pattern>/</url-pattern>
>
> /* and / are the same, logically.
>
> It's possible that mapping to "/" will do horrible things. Have you
> looked at the log files when you start up with this configuration?
>
> You should remove "/" and leave "/*".
>
> > </filter-mapping>
> >
> > For database we have created a request to DB team to get more
> > information about that, but as this is a very complex tool and tool
> > itself creates database connection, it is very hard to identify the
> > exact table.
>
> Okay... what about using the tool on a working server, and then trying
> to load the data on a non-working server? Or entering data on a
> non-working server and looking at the data from a working server?
>
We have one Application server and multiple nodes.
>
> - -chris
>
> > On Wed, Oct 7, 2015 at 11:52 AM, Christopher Schultz <
> > chris@christopherschultz.net> wrote:
> >
> > Saurav,
> >
> > On 10/6/15 9:37 AM, Saurav Maulick wrote:
> >>>> Please find my answer below
> >>>>
> >>>>
> >>>> *Two new clusters or two new nodes added to an existing
> >>>> cluster?*
> >>>>
> >>>> Two Nodes
> >>>>
> >>>>
> >>>> *What is the difference between the conf/server.xml on a
> >>>> "working" server and one of these new servers that is
> >>>> misbehaving?*
> >>>>
> >>>> No difference. Apart from Server port –Configuration,
> >>>> non-SSL HTTP/1.1Connector port Configuration, AJP 1.3
> >>>> Connector port Configuration, and jvmRoute Configuration
> >>>>
> >>>>
> >>>> *Identical WAR files deployed to all servers?*
> >>>>
> >>>> Yes all the nodes have identical WAR file
> >
> > The problem here is usually with the <Connector> URIEncoding
> > setting (probably should be UTF-8 these days) or with clients who
> > send a content-type header without specifying the character
> > encoding, leaving the server to default to ISO-8851-1 (instead of
> > UTF-8, which ought to be the default these days).
> >
> > Tomcat 8 uses UTF-8 as the default <Connector> URIEncoding, unless
> > the system property org.apache.catalina.STRICT_SERVLET_COMPLIANCE
> > is set to true. Tomcat 5.5 *always* uses ISO-8859-1 as the
> > default. http://tomcat.apache.org/tomcat-8.0-doc/config/http.html
> > http://tomcat.apache.org/tomcat-5.5-doc/config/http.html
> >
> > Mikel was asking about <filter> in Tomcat's conf/web.xml because
> > it's typical these days to use a SetCharacterEncodingFilter to
> > override the HTTP-spec-defined requirement that ISO-8859-1 be used
> > when the client does not specify a character set.
> > http://tomcat.apache.org/tomcat-8.0-doc/config/filter.html#Set_Charact
> er
> >
> >
> _Encoding_Filter
> > http://tomcat.apache.org/tomcat-5.5-doc/config/filter.html#Set_Charact
> er
> >
> >
> _Encoding_Filter
> >
> > Finally, you should double-check your database connection
> > configuration. If you have the character set incorrect, there, you
> > can break data in both directions from the database.
> >
> > Can you tell if the characters are broken for GET vs POST
> > requests? Can you check to see if this is an input or output
> > problem? You can check the string in the database to see if the
> > error is present there?
> >
> > Have a read through this document; it will help you look at all
> > the places where there might be a problems:
> > http://wiki.apache.org/tomcat/FAQ/CharacterEncoding#Q8
> >
> > -chris
> >>
> >> ---------------------------------------------------------------------
> >>
> >>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >>
> >
> >
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJWFtwWAAoJEBzwKT+lPKRYgfcQAJPassljlzJBkz6+o1Cyermq
> f8av6GRPYj6tckj3VuLX6aw/EjXrB97WViRTbY/l22XkE1kuXRbnJLf4NiDOgrhb
> yRcdlORK0VUwc51bH6RS3ogcNfLRg+90wp+6QkfI/v5Fj4Gsf5pigZwgdzBr3WkE
> JhYh6AEsSA6HZ4G8CKdjmi1xFF53/tdnKq6ax/jT1NwKNutLYz+NltYQ3wkPHhrA
> 8uTGuXpeDVz3NV10COAaQ87+q+7frz1dlKe7RvSJSVCZiiaccZMzPBFvUD+ayjHG
> QAoDE40b19U6hVSVcEBQwoCcLnZrrTHp8bQW10CoEdcEc+9QiEvfwJbQdbNPCyPE
> aUXEmdWwES6ImDyo5nqYXtDSIBSSu4wp/PcDMILaSp0JeB/TUkxvGJyudgUKZNli
> NTHR5dbsl1kd8uGEoK09Os767ioAdzNrNuLlTeT3J0lvg9USPIpvbpuqV0hmGUqo
> 4bJWTlEVtuWkDlDD/TXXZ6X1Kuf++wcj5r4VGLCSejh7YAHFDtx+ehmMPPItlk+U
> uhE0EpYMp0gx04brA51Kh79hkvBWR8mspniAtxWdgefcXcaUgysJTWcn0BHmlbE1
> fEhWGsJLLqNwzMBmogc4HgrKZHC2W4pljmcstU0tO90SoV657vHkOLK+f1x1DuN8
> 1p4Qwqq4bv0jwI4YBJJW
> =iqrZ
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
Thanks and Regards,
Saurav
Re: Tomcat bad char issue with new cluster
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Saurav,
On 10/8/15 4:45 PM, Saurav Maulick wrote:
> URIEncoding setting is present in both the HTTP Connector and AJP
> Connector.
... and what is the value of that attribute?
> <filter> is not present in the conf/web.xml.
Where? The working or non-working nodes? Or both?
The real question is "what is making the working nodes work". The
you'll have the answer to the question "what do I need to do to my
non-working nodes to make them work".
It might end up being something simple like LC_CTYPE environment
variable on one system versus the other. It *should not* be something
like that -- there is configuration available everywhere for setting
the character encoding of the data being handled, but things like
database drivers might default to using the local default encoding.
> when I try to add <filter> it gives HTTP Status 404" error (please
> see the below <filter> code
>
> <filter>
>
> <filter-name>SetCharacterEncoding</filter-name>
>
>
> <filter-class>org.apache.catalina.filters.SetCharacterEncodingFilter</
filter-class>
>
> <init-param>
>
> <param-name>encoding</param-name>
>
> <param-value>UTF-8</param-value>
>
> </init-param>
>
> </filter>
>
>
>
> <filter-mapping>
>
> <filter-name>SetCharacterEncoding</filter-name>
>
> <url-pattern>/*</url-pattern>
>
> <url-pattern>/</url-pattern>
/* and / are the same, logically.
It's possible that mapping to "/" will do horrible things. Have you
looked at the log files when you start up with this configuration?
You should remove "/" and leave "/*".
> </filter-mapping>
>
> For database we have created a request to DB team to get more
> information about that, but as this is a very complex tool and tool
> itself creates database connection, it is very hard to identify the
> exact table.
Okay... what about using the tool on a working server, and then trying
to load the data on a non-working server? Or entering data on a
non-working server and looking at the data from a working server?
- -chris
> On Wed, Oct 7, 2015 at 11:52 AM, Christopher Schultz <
> chris@christopherschultz.net> wrote:
>
> Saurav,
>
> On 10/6/15 9:37 AM, Saurav Maulick wrote:
>>>> Please find my answer below
>>>>
>>>>
>>>> *Two new clusters or two new nodes added to an existing
>>>> cluster?*
>>>>
>>>> Two Nodes
>>>>
>>>>
>>>> *What is the difference between the conf/server.xml on a
>>>> "working" server and one of these new servers that is
>>>> misbehaving?*
>>>>
>>>> No difference. Apart from Server port –Configuration,
>>>> non-SSL HTTP/1.1Connector port Configuration, AJP 1.3
>>>> Connector port Configuration, and jvmRoute Configuration
>>>>
>>>>
>>>> *Identical WAR files deployed to all servers?*
>>>>
>>>> Yes all the nodes have identical WAR file
>
> The problem here is usually with the <Connector> URIEncoding
> setting (probably should be UTF-8 these days) or with clients who
> send a content-type header without specifying the character
> encoding, leaving the server to default to ISO-8851-1 (instead of
> UTF-8, which ought to be the default these days).
>
> Tomcat 8 uses UTF-8 as the default <Connector> URIEncoding, unless
> the system property org.apache.catalina.STRICT_SERVLET_COMPLIANCE
> is set to true. Tomcat 5.5 *always* uses ISO-8859-1 as the
> default. http://tomcat.apache.org/tomcat-8.0-doc/config/http.html
> http://tomcat.apache.org/tomcat-5.5-doc/config/http.html
>
> Mikel was asking about <filter> in Tomcat's conf/web.xml because
> it's typical these days to use a SetCharacterEncodingFilter to
> override the HTTP-spec-defined requirement that ISO-8859-1 be used
> when the client does not specify a character set.
> http://tomcat.apache.org/tomcat-8.0-doc/config/filter.html#Set_Charact
er
>
>
_Encoding_Filter
> http://tomcat.apache.org/tomcat-5.5-doc/config/filter.html#Set_Charact
er
>
>
_Encoding_Filter
>
> Finally, you should double-check your database connection
> configuration. If you have the character set incorrect, there, you
> can break data in both directions from the database.
>
> Can you tell if the characters are broken for GET vs POST
> requests? Can you check to see if this is an input or output
> problem? You can check the string in the database to see if the
> error is present there?
>
> Have a read through this document; it will help you look at all
> the places where there might be a problems:
> http://wiki.apache.org/tomcat/FAQ/CharacterEncoding#Q8
>
> -chris
>>
>> ---------------------------------------------------------------------
>>
>>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
>
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJWFtwWAAoJEBzwKT+lPKRYgfcQAJPassljlzJBkz6+o1Cyermq
f8av6GRPYj6tckj3VuLX6aw/EjXrB97WViRTbY/l22XkE1kuXRbnJLf4NiDOgrhb
yRcdlORK0VUwc51bH6RS3ogcNfLRg+90wp+6QkfI/v5Fj4Gsf5pigZwgdzBr3WkE
JhYh6AEsSA6HZ4G8CKdjmi1xFF53/tdnKq6ax/jT1NwKNutLYz+NltYQ3wkPHhrA
8uTGuXpeDVz3NV10COAaQ87+q+7frz1dlKe7RvSJSVCZiiaccZMzPBFvUD+ayjHG
QAoDE40b19U6hVSVcEBQwoCcLnZrrTHp8bQW10CoEdcEc+9QiEvfwJbQdbNPCyPE
aUXEmdWwES6ImDyo5nqYXtDSIBSSu4wp/PcDMILaSp0JeB/TUkxvGJyudgUKZNli
NTHR5dbsl1kd8uGEoK09Os767ioAdzNrNuLlTeT3J0lvg9USPIpvbpuqV0hmGUqo
4bJWTlEVtuWkDlDD/TXXZ6X1Kuf++wcj5r4VGLCSejh7YAHFDtx+ehmMPPItlk+U
uhE0EpYMp0gx04brA51Kh79hkvBWR8mspniAtxWdgefcXcaUgysJTWcn0BHmlbE1
fEhWGsJLLqNwzMBmogc4HgrKZHC2W4pljmcstU0tO90SoV657vHkOLK+f1x1DuN8
1p4Qwqq4bv0jwI4YBJJW
=iqrZ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat bad char issue with new cluster
Posted by Saurav Maulick <sa...@gmail.com>.
Hi Christopher,
URIEncoding setting is present in both the HTTP Connector and AJP Connector.
<filter> is not present in the conf/web.xml. when I try to add <filter> it
gives HTTP Status 404" error (please see the below <filter> code
<filter>
<filter-name>SetCharacterEncoding</filter-name>
<filter-class>org.apache.catalina.filters.SetCharacterEncodingFilter</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>UTF-8</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>SetCharacterEncoding</filter-name>
<url-pattern>/*</url-pattern>
<url-pattern>/</url-pattern>
</filter-mapping>
For database we have created a request to DB team to get more information
about that, but as this is a very complex tool and tool itself creates
database connection, it is very hard to identify the exact table.
On Wed, Oct 7, 2015 at 11:52 AM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Saurav,
>
> On 10/6/15 9:37 AM, Saurav Maulick wrote:
> > Please find my answer below
> >
> >
> > *Two new clusters or two new nodes added to an existing cluster?*
> >
> > Two Nodes
> >
> >
> > *What is the difference between the conf/server.xml on a "working"
> > server and one of these new servers that is misbehaving?*
> >
> > No difference. Apart from Server port –Configuration, non-SSL
> > HTTP/1.1Connector port Configuration, AJP 1.3 Connector port
> > Configuration, and jvmRoute Configuration
> >
> >
> > *Identical WAR files deployed to all servers?*
> >
> > Yes all the nodes have identical WAR file
>
> The problem here is usually with the <Connector> URIEncoding setting
> (probably should be UTF-8 these days) or with clients who send a
> content-type header without specifying the character encoding, leaving
> the server to default to ISO-8851-1 (instead of UTF-8, which ought to
> be the default these days).
>
> Tomcat 8 uses UTF-8 as the default <Connector> URIEncoding, unless the
> system property org.apache.catalina.STRICT_SERVLET_COMPLIANCE is set
> to true. Tomcat 5.5 *always* uses ISO-8859-1 as the default.
> http://tomcat.apache.org/tomcat-8.0-doc/config/http.html
> http://tomcat.apache.org/tomcat-5.5-doc/config/http.html
>
> Mikel was asking about <filter> in Tomcat's conf/web.xml because it's
> typical these days to use a SetCharacterEncodingFilter to override the
> HTTP-spec-defined requirement that ISO-8859-1 be used when the client
> does not specify a character set.
> http://tomcat.apache.org/tomcat-8.0-doc/config/filter.html#Set_Character
> _Encoding_Filter
> http://tomcat.apache.org/tomcat-5.5-doc/config/filter.html#Set_Character
> _Encoding_Filter
>
> Finally, you should double-check your database connection
> configuration. If you have the character set incorrect, there, you can
> break data in both directions from the database.
>
> Can you tell if the characters are broken for GET vs POST requests?
> Can you check to see if this is an input or output problem? You can
> check the string in the database to see if the error is present there?
>
> Have a read through this document; it will help you look at all the
> places where there might be a problems:
> http://wiki.apache.org/tomcat/FAQ/CharacterEncoding#Q8
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJWFT/OAAoJEBzwKT+lPKRYgKgP/iIkQe7b4K4NLPCUENIQY+xU
> 8brkeF1z60kJdtoBQvx0FtzpO6ri0GUXKK9S/3PNxPq8YlMm+lLc3lMhjHD8PlVR
> jx7zlvBTdpfyYm2flB3WHWP5W36Ii1kkUlCdVv1uaemov9++AA/ACK1HDUAWUD+J
> Jiho+tg+9qjoOAVcUVGXkLb1pkeXB8GZb5pbdG9w6igKevcAOxYs0yoBJ1FLx08A
> 0ONpGI4VJplvFI1UyOBwU8hqAuUb5d4PUxmwPCoE4j7vcadsgJSxOikClPHQQYfN
> GrQtSgo0MzMfAKDB4AHZtWkX/P6Yj79977y9W8fcDc27NtOoJeZzEMTsQfG/kzeK
> UyJxu+F9C2l0iTGx+e/BZjYf0fvfBk6wxzivPCb6UWZhjHxNkrFW8GNZio5G67iK
> jZ+qNbk6QNiEbFdCZVgUrTAF2H6LL0mW7hwhLdB4+ASeD3xwTsXVg+IuR7DPxjOp
> bNIOin6IKgIDKpQYPsZKw8y20XomxDhV7FxTbmLc//ApXultUiZ5DhNBB+kD63+b
> pXkL6RT7GUohVN2lF7J02A8LlyQgGRqOakTjJ3swAfVGlcT+eleleBUUGvk+EaQQ
> QJPlIi7dO+Rn7El7o/BNByaBZZ3SfJn8BOhwHaKQWZJjSBxpXGinv3SyFxKjh59c
> V3Ufu0KAnJ9I1NRqv/4D
> =owkM
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
Thanks and Regards,
Saurav
Re: Tomcat bad char issue with new cluster
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Saurav,
On 10/6/15 9:37 AM, Saurav Maulick wrote:
> Please find my answer below
>
>
> *Two new clusters or two new nodes added to an existing cluster?*
>
> Two Nodes
>
>
> *What is the difference between the conf/server.xml on a "working"
> server and one of these new servers that is misbehaving?*
>
> No difference. Apart from Server port –Configuration, non-SSL
> HTTP/1.1Connector port Configuration, AJP 1.3 Connector port
> Configuration, and jvmRoute Configuration
>
>
> *Identical WAR files deployed to all servers?*
>
> Yes all the nodes have identical WAR file
The problem here is usually with the <Connector> URIEncoding setting
(probably should be UTF-8 these days) or with clients who send a
content-type header without specifying the character encoding, leaving
the server to default to ISO-8851-1 (instead of UTF-8, which ought to
be the default these days).
Tomcat 8 uses UTF-8 as the default <Connector> URIEncoding, unless the
system property org.apache.catalina.STRICT_SERVLET_COMPLIANCE is set
to true. Tomcat 5.5 *always* uses ISO-8859-1 as the default.
http://tomcat.apache.org/tomcat-8.0-doc/config/http.html
http://tomcat.apache.org/tomcat-5.5-doc/config/http.html
Mikel was asking about <filter> in Tomcat's conf/web.xml because it's
typical these days to use a SetCharacterEncodingFilter to override the
HTTP-spec-defined requirement that ISO-8859-1 be used when the client
does not specify a character set.
http://tomcat.apache.org/tomcat-8.0-doc/config/filter.html#Set_Character
_Encoding_Filter
http://tomcat.apache.org/tomcat-5.5-doc/config/filter.html#Set_Character
_Encoding_Filter
Finally, you should double-check your database connection
configuration. If you have the character set incorrect, there, you can
break data in both directions from the database.
Can you tell if the characters are broken for GET vs POST requests?
Can you check to see if this is an input or output problem? You can
check the string in the database to see if the error is present there?
Have a read through this document; it will help you look at all the
places where there might be a problems:
http://wiki.apache.org/tomcat/FAQ/CharacterEncoding#Q8
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJWFT/OAAoJEBzwKT+lPKRYgKgP/iIkQe7b4K4NLPCUENIQY+xU
8brkeF1z60kJdtoBQvx0FtzpO6ri0GUXKK9S/3PNxPq8YlMm+lLc3lMhjHD8PlVR
jx7zlvBTdpfyYm2flB3WHWP5W36Ii1kkUlCdVv1uaemov9++AA/ACK1HDUAWUD+J
Jiho+tg+9qjoOAVcUVGXkLb1pkeXB8GZb5pbdG9w6igKevcAOxYs0yoBJ1FLx08A
0ONpGI4VJplvFI1UyOBwU8hqAuUb5d4PUxmwPCoE4j7vcadsgJSxOikClPHQQYfN
GrQtSgo0MzMfAKDB4AHZtWkX/P6Yj79977y9W8fcDc27NtOoJeZzEMTsQfG/kzeK
UyJxu+F9C2l0iTGx+e/BZjYf0fvfBk6wxzivPCb6UWZhjHxNkrFW8GNZio5G67iK
jZ+qNbk6QNiEbFdCZVgUrTAF2H6LL0mW7hwhLdB4+ASeD3xwTsXVg+IuR7DPxjOp
bNIOin6IKgIDKpQYPsZKw8y20XomxDhV7FxTbmLc//ApXultUiZ5DhNBB+kD63+b
pXkL6RT7GUohVN2lF7J02A8LlyQgGRqOakTjJ3swAfVGlcT+eleleBUUGvk+EaQQ
QJPlIi7dO+Rn7El7o/BNByaBZZ3SfJn8BOhwHaKQWZJjSBxpXGinv3SyFxKjh59c
V3Ufu0KAnJ9I1NRqv/4D
=owkM
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat bad char issue with new cluster
Posted by Saurav Maulick <sa...@gmail.com>.
Hi Christopher,
Please find my answer below
*Two new clusters or two new nodes added to an existing cluster?*
Two Nodes
*What is the difference between the conf/server.xml on a "working" server
and one of these new servers that is misbehaving?*
No difference. Apart from Server port –Configuration, non-SSL
HTTP/1.1Connector port Configuration, AJP 1.3 Connector port Configuration,
and jvmRoute Configuration
*Identical WAR files deployed to all servers?*
Yes all the nodes have identical WAR file
On Mon, Oct 5, 2015 at 9:06 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Saurav,
>
> On 10/5/15 12:23 PM, Saurav Maulick wrote:
> > I know Tomcat 5.5 is very old and this is outdated, but we are
> > still using Tomcat 5.5 and we got an issue. Please help.
> >
> > Problem description:
> >
> > Recently my client has asked me to add two new clusters in the
> > production, after adding the clusters we found that these two new
> > clusters are not able to handle special characters.
>
> Two new clusters, or two new nodes added to an existing cluster?
>
> > When user copies some data (especially from MS-Word which contains
> > double quote) and paste into the application we have found that
> > double quote becomes junk character, but these problems only
> > persist with newly created clusters not with old clusters.
> >
> > While creating the new cluster I just copied the old cluster folder
> > and all the clusters are identical except some changes in
> > server.xml.
> >
> > Could you please help me to resolve this issue?
> >
> > NB. UTF-8 char encoding present in the xml files
>
> What is the difference between the conf/server.xml on a "working"
> server and one of these new servers that is misbehaving? Identical WAR
> files deployed to all servers?
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJWEx6mAAoJEBzwKT+lPKRYPzIP/iFpPGH+zfPOsgwtqhnqe5ou
> 5PqaVEJ0G9+854Gs+q19n9Fcug2NHCnjRaDHj/ujhiOjj2phF1KbWtvEOmMeH6rG
> QpuPTPr6DJZiEZpnvCaK2tolQEwnO7CqJ1AEqQo/TQ7IzKFx+Ou5SxZ9m8kQeBKg
> ZrPt4vBxrASaELSn+vPPzsA2aBzr9OXijO35Gbjf09FCbR7BC/QnucbAaS6b3z2W
> jxrFDRzv7QTxSoA9c8QdNPdcJXEbLQF59yf/4JO/Bx68A7apneSWjo9zw9POWfD2
> wHysHZJFF8WBbh1lBJXFuyLMT9luu1v4I7nvdYU98S2p9EOqVTnDM84XBVN9xd/r
> TbNGvcIErLsXeNRqHaXSCF95KbjMSdeKCYKfroPz9/xEZUWWpdFRm6OLVTY6mF1F
> WDJZUltgGT/O6iM0x39rcEnwapX5XUlPgpolhhEJFC4PXZgLpwQQTwhEBACtClVn
> 30P4brBZYIW1NIR4Vq7yI0ltpf7CT0X3Y7xSvP53yM5zIpcmwQsWVCnle+8XY9bz
> 4msgAfpp5Xb2q3ovGwrCKahWCeddTofUfgqCBmg7fgvD7K7812rSgjOQ617QgNl5
> FZnt9Td79vcWe7I8J1vJdvWTymuydfVMWEu5ptOpORwsGdWVYI/qnOTCl+b8XW7K
> oVU1afvuvfBA+abbnz/L
> =e9Is
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
Thanks and Regards,
Saurav
Re: Tomcat bad char issue with new cluster
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Saurav,
On 10/5/15 12:23 PM, Saurav Maulick wrote:
> I know Tomcat 5.5 is very old and this is outdated, but we are
> still using Tomcat 5.5 and we got an issue. Please help.
>
> Problem description:
>
> Recently my client has asked me to add two new clusters in the
> production, after adding the clusters we found that these two new
> clusters are not able to handle special characters.
Two new clusters, or two new nodes added to an existing cluster?
> When user copies some data (especially from MS-Word which contains
> double quote) and paste into the application we have found that
> double quote becomes junk character, but these problems only
> persist with newly created clusters not with old clusters.
>
> While creating the new cluster I just copied the old cluster folder
> and all the clusters are identical except some changes in
> server.xml.
>
> Could you please help me to resolve this issue?
>
> NB. UTF-8 char encoding present in the xml files
What is the difference between the conf/server.xml on a "working"
server and one of these new servers that is misbehaving? Identical WAR
files deployed to all servers?
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJWEx6mAAoJEBzwKT+lPKRYPzIP/iFpPGH+zfPOsgwtqhnqe5ou
5PqaVEJ0G9+854Gs+q19n9Fcug2NHCnjRaDHj/ujhiOjj2phF1KbWtvEOmMeH6rG
QpuPTPr6DJZiEZpnvCaK2tolQEwnO7CqJ1AEqQo/TQ7IzKFx+Ou5SxZ9m8kQeBKg
ZrPt4vBxrASaELSn+vPPzsA2aBzr9OXijO35Gbjf09FCbR7BC/QnucbAaS6b3z2W
jxrFDRzv7QTxSoA9c8QdNPdcJXEbLQF59yf/4JO/Bx68A7apneSWjo9zw9POWfD2
wHysHZJFF8WBbh1lBJXFuyLMT9luu1v4I7nvdYU98S2p9EOqVTnDM84XBVN9xd/r
TbNGvcIErLsXeNRqHaXSCF95KbjMSdeKCYKfroPz9/xEZUWWpdFRm6OLVTY6mF1F
WDJZUltgGT/O6iM0x39rcEnwapX5XUlPgpolhhEJFC4PXZgLpwQQTwhEBACtClVn
30P4brBZYIW1NIR4Vq7yI0ltpf7CT0X3Y7xSvP53yM5zIpcmwQsWVCnle+8XY9bz
4msgAfpp5Xb2q3ovGwrCKahWCeddTofUfgqCBmg7fgvD7K7812rSgjOQ617QgNl5
FZnt9Td79vcWe7I8J1vJdvWTymuydfVMWEu5ptOpORwsGdWVYI/qnOTCl+b8XW7K
oVU1afvuvfBA+abbnz/L
=e9Is
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org