Hi Christopher,

On Thu, Oct 8, 2015 at 5:11 PM, Christopher Schultz <
ch...@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 <
> > ch...@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-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@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-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
Thanks and Regards,
Saurav

Reply via email to