Re: isHexDigit error problems and upgrading Tomcat and jdk
-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: >> >> > 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 > > directory="logs" prefix="localhost_access_log." suffix=".txt" > pattern="%h %l %u %t "%r" %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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: isHexDigit error problems and upgrading Tomcat and jdk
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: 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 directory="logs" prefix="localhost_access_log." suffix=".txt" pattern="%h %l %u %t "%r" %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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: isHexDigit error problems and upgrading Tomcat and jdk
-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: 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: isHexDigit error problems and upgrading Tomcat and jdk
-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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: isHexDigit error problems and upgrading Tomcat and jdk
2012/6/7 Miguel González Castaños : > On 07/06/2012 00:54, Konstantin Kolinko wrote: >> >> 2012/6/7 Miguel González Castaños: >>> >>> 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: isHexDigit error problems and upgrading Tomcat and jdk
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: isHexDigit error problems and upgrading Tomcat and jdk
On 07/06/2012 00:54, Konstantin Kolinko wrote: 2012/6/7 Miguel González Castaños: 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: isHexDigit error problems and upgrading Tomcat and jdk
2012/6/7 Miguel González Castaños : > 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org