You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Miguel González Castaños <mi...@yahoo.es> on 2012/06/07 00:40:49 UTC

isHexDigit error problems and upgrading Tomcat and jdk

Hi,

   We are getting isHexDigit errors again, although there is no 
malformed URL requests

   We are using Tomcat 5.5 and jdk 1.5 (from Sun). As some of you have 
suggested me in the past, I'm considering to upgrade to a more 
up-to-date Tomcat and/or jdk so I can get more support and help from the 
community since probably the stability issues are solved in newer 
versions. I have set up a test environment and Tomcat 7.0.27 and jdk 1.7 
seems to work fine.

   Do you suggest me to upgrade to Tomcat 6 or 7? What about jdk? 1.6 or 
1.7?

  Thanks

  Miguel


-----------------------------


Jun 6, 2012 9:05:59 AM org.apache.tomcat.util.http.Parameters 
processParameters
WARNING: Parameters: Character decoding failed. Parameter skipped.
java.io.CharConversionException: isHexDigit
         at org.apache.tomcat.util.buf.UDecoder.convert(UDecoder.java:87)
         at org.apache.tomcat.util.buf.UDecoder.convert(UDecoder.java:48)
         at 
org.apache.tomcat.util.http.Parameters.urlDecode(Parameters.java:411)
         at 
org.apache.tomcat.util.http.Parameters.processParameters(Parameters.java:393)
         at 
org.apache.tomcat.util.http.Parameters.processParameters(Parameters.java:344)
         at 
org.apache.catalina.connector.Request.parseParameters(Request.java:2401)
         at 
org.apache.catalina.connector.Request.getParameterNames(Request.java:1047)
         at 
org.apache.catalina.connector.RequestFacade.getParameterNames(RequestFacade.java:369)
         at 
javax.servlet.ServletRequestWrapper.getParameterNames(ServletRequestWrapper.java:178)
         at 
org.apache.struts.util.RequestUtils.populate(RequestUtils.java:1225)
         at 
org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:821)
         at 
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:254)
         at 
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
         at 
org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:647)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
         at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
         at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
         at 
net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:185)
         at 
net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:159)
         at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
         at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
         at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
         at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172)
         at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
         at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
         at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
         at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
         at 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:875)
         at 
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
         at 
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
         at 
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
         at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
         at java.lang.Thread.run(Thread.java:595)

Jun 6, 2012 10:15:22 AM org.apache.coyote.http11.Http11BaseProtocol pause
INFO: Pausing Coyote HTTP/1.1 on http-80
Jun 6, 2012 10:15:22 AM org.apache.coyote.http11.Http11BaseProtocol pause
INFO: Pausing Coyote HTTP/1.1 on http-443

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: isHexDigit error problems and upgrading Tomcat and jdk

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Miguel,

On 6/7/12 5:51 PM, Miguel González Castaños wrote:
> 
>> That depends upon how you have configured your access log: you
>> can configure an access log to log only requests that failed and
>> the details of that request like this:
>> 
>> <Valve className="org.apache.catalina.valves.AccessLogValve" 
>> conditionIf="org.apache.catalina.parameter_parse_failed" .... />
>> 
>> You will probably want to put "%t" and "%r" in your pattern.
> 
> This looks interesting. In my test environment (with Tomcat 7 and
> java 1.7) it shows by default
> 
> <Valve className="org.apache.catalina.valves.AccessLogValve" 
> directory="logs" prefix="localhost_access_log." suffix=".txt" 
> pattern="%h %l %u %t &quot;%r&quot; %s %b" />
> 
> this should keep track of the errors just adding just the entry:
> 
> conditionIf="org.apache.catalina.parameter_parse_failed"

You'll never know what the POST contents were in this case. So, if the
broken parameter comes as part of the POST, you'll get no more
information than you would get in your usual access log (except that
you'll know the specific request failed).

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/UuNcACgkQ9CaO5/Lv0PD8jwCfY2KWiapFA2sdbPyqNrAZnYXG
pesAnRgk1bEpAUv8VXupYiInn29xTjat
=Owuw
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: isHexDigit error problems and upgrading Tomcat and jdk

Posted by Miguel González Castaños <mi...@yahoo.es>.
> That depends upon how you have configured your access log: you can
> configure an access log to log only requests that failed and the
> details of that request like this:
>
> <Valve className="org.apache.catalina.valves.AccessLogValve"
>       conditionIf="org.apache.catalina.parameter_parse_failed"
>       ....
>       />
>
> You will probably want to put "%t" and "%r" in your pattern.

This looks interesting. In my test environment (with Tomcat 7 and java 
1.7) it shows by default

<Valve className="org.apache.catalina.valves.AccessLogValve" 
directory="logs"
                prefix="localhost_access_log." suffix=".txt"
                pattern="%h %l %u %t &quot;%r&quot; %s %b" />

this should keep track of the errors just adding just the entry:

conditionIf="org.apache.catalina.parameter_parse_failed"


?

>
> Unfortunately, this is a POST that is being processed and it's hard to
> use the RequestDumperFilter to dump the requests of only certain
> requests.... that might be the only way to get the offending parameter
> name or value that is causing this problem.
Many thanks for your hints :)

Miguel

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: isHexDigit error problems and upgrading Tomcat and jdk

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Miguel,

On 6/7/12 4:13 AM, Miguel González Castaños wrote:
> On 07/06/2012 00:54, Konstantin Kolinko wrote:
>> It is parameter parsing code. It cannot claim the request as
>> malformed (API does not allow it). It can only skip malformed
>> parameters.
> 
> Does that mean that it won't show up in the access log?

That depends upon how you have configured your access log: you can
configure an access log to log only requests that failed and the
details of that request like this:

<Valve className="org.apache.catalina.valves.AccessLogValve"
     conditionIf="org.apache.catalina.parameter_parse_failed"
     ....
     />

You will probably want to put "%t" and "%r" in your pattern.

Unfortunately, this is a POST that is being processed and it's hard to
use the RequestDumperFilter to dump the requests of only certain
requests.... that might be the only way to get the offending parameter
name or value that is causing this problem.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/Q6dEACgkQ9CaO5/Lv0PA6bQCfcHsaExvYzrgBFl9WM+3Lg+DS
cssAnR1rCga318tOzveCdGDho+5/FCE+
=lPTF
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: isHexDigit error problems and upgrading Tomcat and jdk

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Miguel,

On 6/7/12 4:13 AM, Miguel González Castaños wrote:
> It's not a new system, it's been running for 3 years already. I
> don't want to risk that any library has changed its behavior with
> tomcat 7 or something similar.

I don't believe it's less risky to move up to Tomcat 6 than it is to
move to Tomcat 7.

>> I heard that Oracle plans to stop provide free updates for 1.6
>> this summer. So they will be available only as "Java for
>> Business".
> 
> Does it mean that it is probably better to go for 1.7 instead?

Only you can guess what is better for you. As with the Tomcat upgrade,
I don't believe it's any less risky to upgrade to Java 1.6 than it is
to upgrade to Java 1.6.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/Q59QACgkQ9CaO5/Lv0PD+MQCcCLvc3rlplLhyFyI8k5+f0GKH
mYEAoJzmI5JWAYYXPX1ZilSblGbNMTW2
=dg6q
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: isHexDigit error problems and upgrading Tomcat and jdk

Posted by Konstantin Kolinko <kn...@gmail.com>.
2012/6/7 Miguel González Castaños <mi...@yahoo.es>:
> On 07/06/2012 00:54, Konstantin Kolinko wrote:
>>
>> 2012/6/7 Miguel González Castaños<mi...@yahoo.es>:
>>>
>>> Hi,
>>>
>>>  We are getting isHexDigit errors again, although there is no malformed
>>> URL
>>> requests
>>
>> It is parameter parsing code. It cannot claim the request as malformed
>> (API does not allow it). It can only skip malformed parameters.
>
> Does that mean that it won't show up in the access log?

Yes, it would not show in access log.

> It is a problem with
> a parameter used by the parsing code?

It is problem with parameters submitted by client. Broken parameters
are ignored (and this warning is printed).

Parameters parsing is performed lazily on your first call to
getParameter() or similar methods. It is not allowed to fail.

In recent versions of Tomcat this and similar failures set a flag in
the request object to signal that an error happened.  This flag can be
tested by your code (using FailedRequestFilter as an example),  or you
can just configure and use FailedRequestFilter  as is, if it is
available in that version of Tomcat.

What ever you do upon detecting the failure - is your choice. The
FailedRequestFilter  rejects the request.

> How can I log any info that could show
> where is the problem in the code or when is this happening? It's making
> Tomcat to pause and then to stop.
>

This failure cannot make Tomcat pause and stop.

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: isHexDigit error problems and upgrading Tomcat and jdk

Posted by Stefan Mayr <st...@mayr-stefan.de>.
Am 07.06.2012 10:13, schrieb Miguel González Castaños:
> ...
>>>   Do you suggest me to upgrade to Tomcat 6 or 7? What about jdk? 1.6
>>> or 1.7?
>> 1.6 is more widely tested (many years), but for a new system I would
>> go with 1.7.
> It's not a new system, it's been running for 3 years already. I don't
> want to risk that any library has changed its behavior with tomcat 7 or
> something similar.
>>
>> I heard that Oracle plans to stop provide free updates for 1.6 this
>> summer. So they will be available only as "Java for Business".
> Does it mean that it is probably better to go for 1.7 instead?

Maybe you should have a look at oracles lifecycle policy: 
http://www.oracle.com/technetwork/java/eol-135779.html

If you need to provide a secure system with current patches you should 
take the effort to upgrade to java 7. This provides you with 3 more 
years of Oracle updates.

    Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: isHexDigit error problems and upgrading Tomcat and jdk

Posted by Miguel González Castaños <mi...@yahoo.es>.
On 07/06/2012 00:54, Konstantin Kolinko wrote:
> 2012/6/7 Miguel González Castaños<mi...@yahoo.es>:
>> Hi,
>>
>>   We are getting isHexDigit errors again, although there is no malformed URL
>> requests
> It is parameter parsing code. It cannot claim the request as malformed
> (API does not allow it). It can only skip malformed parameters.
Does that mean that it won't show up in the access log? It is a problem 
with a parameter used by the parsing code? How can I log any info that 
could show where is the problem in the code or when is this happening? 
It's making Tomcat to pause and then to stop.

>
> It sets some error flag that can be examined. FailedRequestFilter is
> example of a filter that checks that flag.
I understand that function has to be added in the parsing code, isn't it?

>
>>   We are using Tomcat 5.5 and jdk 1.5 (from Sun). As some of you have
>> suggested me in the past, I'm considering to upgrade to a more up-to-date
>> Tomcat and/or jdk so I can get more support and help from the community
>> since probably the stability issues are solved in newer versions. I have set
>> up a test environment and Tomcat 7.0.27 and jdk 1.7 seems to work fine.
>>
>>   Do you suggest me to upgrade to Tomcat 6 or 7? What about jdk? 1.6 or 1.7?
> 1.6 is more widely tested (many years), but for a new system I would
> go with 1.7.
It's not a new system, it's been running for 3 years already. I don't 
want to risk that any library has changed its behavior with tomcat 7 or 
something similar.
>
> I heard that Oracle plans to stop provide free updates for 1.6 this
> summer. So they will be available only as "Java for Business".
Does it mean that it is probably better to go for 1.7 instead?

Miguel

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: isHexDigit error problems and upgrading Tomcat and jdk

Posted by Konstantin Kolinko <kn...@gmail.com>.
2012/6/7 Miguel González Castaños <mi...@yahoo.es>:
> Hi,
>
>  We are getting isHexDigit errors again, although there is no malformed URL
> requests

It is parameter parsing code. It cannot claim the request as malformed
(API does not allow it). It can only skip malformed parameters.

It sets some error flag that can be examined. FailedRequestFilter is
example of a filter that checks that flag.

>  We are using Tomcat 5.5 and jdk 1.5 (from Sun). As some of you have
> suggested me in the past, I'm considering to upgrade to a more up-to-date
> Tomcat and/or jdk so I can get more support and help from the community
> since probably the stability issues are solved in newer versions. I have set
> up a test environment and Tomcat 7.0.27 and jdk 1.7 seems to work fine.
>
>  Do you suggest me to upgrade to Tomcat 6 or 7? What about jdk? 1.6 or 1.7?

1.6 is more widely tested (many years), but for a new system I would
go with 1.7.

I heard that Oracle plans to stop provide free updates for 1.6 this
summer. So they will be available only as "Java for Business".

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org