FAQ
Hi,

We are having an elusive issue on one of our production servers using
Tomcat 6.0.14, every few minutes we are getting a request that results
in the following exception:

Oct 25, 2007 12:04:23 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:88)
at org.apache.tomcat.util.buf.UDecoder.convert(UDecoder.java:49)
at
org.apache.tomcat.util.http.Parameters.urlDecode(Parameters.java:412)
at
org.apache.tomcat.util.http.Parameters.processParameters(Parameters.java:394)
at
org.apache.tomcat.util.http.Parameters.processParameters(Parameters.java:346)
at
org.apache.catalina.connector.Request.parseParameters(Request.java:2470)
at
org.apache.catalina.connector.Request.getParameter(Request.java:1040)
at
org.apache.catalina.connector.RequestFacade.getParameter(RequestFacade.java:355)
......

Has anyone seen anything like this before, and know how to handle it? It
appears Firefox 2.0.0.8 browsers and IE browsers are both passing POST
commands that are resulting in this exception.

A quick search on google reveals a bunch of other people who dont know
what it is, and well, the source code that throws the exception.

Best Regards,
Jacob

--
_________________________________________________
Jacob Rhoden
Application Architect
Systems Development and Integration
University of Melbourne

Phone: +61 3 8344 2884



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

Search Discussions

  • Jacob Rhoden at Oct 25, 2007 at 1:12 am

    Martin Gainty wrote:
    Please post the encoding attribute located on the top line for you web.xml
    e.g.
    <?xml version="1.0" encoding="UTF-8"?>
    I had wondered if that was relevant. To make sure we handle
    international characters properly we are using:

    <%@ page language="java" contentType="text/html; charset=UTF-8"
    pageEncoding="UTF-8"%>

    And on top of this to make sure the characters are handled properly, we
    have a servlet filter with the following code:
    request.setCharacterEncoding("UTF-8");
    response.setCharacterEncoding("UTF-8");

    With the following to (i assume) apply it to all servlets and JSP's:

    <filter-mapping>
    <filter-name>AuthorisationFilter</filter-name>
    <url-pattern>/*</url-pattern>
    </filter-mapping>

    I assume the filter is working as Chinese characters can now go to and
    from tomcat correctly from a html form. Any help much appreciated.

    Best Regards,
    Jacob
    We are having an elusive issue on one of our production servers using
    Tomcat 6.0.14, every few minutes we are getting a request that results
    in the following exception:

    Oct 25, 2007 12:04:23 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:88)
    at org.apache.tomcat.util.buf.UDecoder.convert(UDecoder.java:49)
    at
    org.apache.tomcat.util.http.Parameters.urlDecode(Parameters.java:412)
    at
    org.apache.tomcat.util.http.Parameters.processParameters(Parameters.java:394
    )
    at
    org.apache.tomcat.util.http.Parameters.processParameters(Parameters.java:346
    )
    at
    org.apache.catalina.connector.Request.parseParameters(Request.java:2470)
    at
    org.apache.catalina.connector.Request.getParameter(Request.java:1040)
    at
    org.apache.catalina.connector.RequestFacade.getParameter(RequestFacade.java:
    355)
    ......

    Has anyone seen anything like this before, and know how to handle it? It
    appears Firefox 2.0.0.8 browsers and IE browsers are both passing POST
    commands that are resulting in this exception.

    A quick search on google reveals a bunch of other people who dont know
    what it is, and well, the source code that throws the exception.

    Best Regards,
    Jacob

    --
    _________________________________________________
    Jacob Rhoden
    Application Architect
    Systems Development and Integration
    University of Melbourne

    Phone: +61 3 8344 2884



    ---------------------------------------------------------------------
    To start a new topic, e-mail: users@tomcat.apache.org
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Mark Thomas at Oct 25, 2007 at 2:03 am

    Jacob Rhoden wrote:
    Martin Gainty wrote:
    Please post the encoding attribute located on the top line for you
    web.xml
    e.g.
    <?xml version="1.0" encoding="UTF-8"?>
    I had wondered if that was relevant.
    This is completely and totally irrelevant with respect to the warning
    you are seeing in the logs.
    To make sure we handle
    international characters properly we are using:
    This is all good.
    I assume the filter is working as Chinese characters can now go to and
    from tomcat correctly from a html form. Any help much appreciated.
    Everything you need to know is there in the stack trace. See below.
    Oct 25, 2007 12:04:23 AM org.apache.tomcat.util.http.Parameters
    processParameters
    WARNING: Parameters: Character decoding failed. Parameter skipped.
    One of your request parameters has been ignored because it could not
    be decoded from %xx form. And the reason ...
    java.io.CharConversionException: isHexDigit
    One of the x characters in %xx is not a hex digit (0-9, A-F).

    Start looking at your requests (I use TcpMon from the Axis project but
    there are plenty of tools that do the same sort of thing) and see
    which of the %xx values is invalid.

    Are you using mod_jk at all? If so, you'll need to look at browser to
    httpd/IIS/etc and httpd/IIS/etc to Tomcat. You can turn up the log
    level to look at the mod_jk messages.

    Mark

    ---------------------------------------------------------------------
    To start a new topic, e-mail: users@tomcat.apache.org
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Jacob Rhoden at Oct 25, 2007 at 2:09 am
    This is as far as I got. Why would the browser be encoding its requests
    in anything other than base64. I had just wondered if this was a common
    problem with a somewhat simple solution. I don't really have time to go
    digging around in TCP dumps at the moment so I guess the error will have
    to live on for the time being, thanks for your feedback.

    Best Regards,
    Jacob

    Mark Thomas wrote:
    One of the x characters in %xx is not a hex digit (0-9, A-F).

    Start looking at your requests (I use TcpMon from the Axis project but
    there are plenty of tools that do the same sort of thing) and see
    which of the %xx values is invalid.

    Are you using mod_jk at all? If so, you'll need to look at browser to
    httpd/IIS/etc and httpd/IIS/etc to Tomcat. You can turn up the log
    level to look at the mod_jk messages.

    --
    _________________________________________________
    Jacob Rhoden
    Application Architect
    Systems Development and Integration
    University of Melbourne

    Phone: +61 3 8344 2884



    ---------------------------------------------------------------------
    To start a new topic, e-mail: users@tomcat.apache.org
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Mark Thomas at Oct 25, 2007 at 2:19 am

    Jacob Rhoden wrote:
    This is as far as I got. Why would the browser be encoding its requests
    in anything other than base64. I had just wondered if this was a common
    problem with a somewhat simple solution. I don't really have time to go
    digging around in TCP dumps at the moment so I guess the error will have
    to live on for the time being, thanks for your feedback.
    Are you using mod_jk? There is a config that could cause this.

    Mark


    ---------------------------------------------------------------------
    To start a new topic, e-mail: users@tomcat.apache.org
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Jacob Rhoden at Oct 25, 2007 at 2:29 am

    Mark Thomas wrote:
    Jacob Rhoden wrote:
    This is as far as I got. Why would the browser be encoding its requests
    in anything other than base64.....
    Are you using mod_jk? There is a config that could cause this.
    We did not configure the server, our provider did.... I just checked and
    eek!! its using mod_jk2! I suspect that would be the reason.

    Best Regards,
    Jacob

    --
    _________________________________________________
    Jacob Rhoden
    Application Architect
    Systems Development and Integration
    University of Melbourne

    Phone: +61 3 8344 2884



    ---------------------------------------------------------------------
    To start a new topic, e-mail: users@tomcat.apache.org
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Mark Thomas at Oct 25, 2007 at 2:47 am

    Jacob Rhoden wrote:
    Mark Thomas wrote:
    Jacob Rhoden wrote:
    This is as far as I got. Why would the browser be encoding its requests
    in anything other than base64.....
    Are you using mod_jk? There is a config that could cause this.
    We did not configure the server, our provider did.... I just checked and
    eek!! its using mod_jk2! I suspect that would be the reason.
    mod_jk2!!! Are you sure. That module has been deprecated for several
    years.

    mod_jk2 may be manipulating the URI. You should be aware of
    CVE-2007-1860 (see http://tomcat.apache.org/security-jk.html). In
    short mod_jk URI handling created a few security holes. We didn't
    check mod_jk2 for this issue.

    For further reading, see
    http://tomcat.apache.org/connectors-doc/reference/apache.html
    particularly the ForwardURIxxx directives.

    HTH,

    Mark

    ---------------------------------------------------------------------
    To start a new topic, e-mail: users@tomcat.apache.org
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Jacob Rhoden at Oct 25, 2007 at 2:56 am
    Hi Mark,

    I was aware that mod_jk2 was deprecated I just did not know that our
    provider setup the system using mod_jk2 until you prompted me to
    investigate. Thanks for your help!

    Best Regards,
    Jacob

    Mark Thomas wrote:
    mod_jk2!!! Are you sure. That module has been deprecated for several
    years.

    mod_jk2 may be manipulating the URI. You should be aware of
    CVE-2007-1860 (see http://tomcat.apache.org/security-jk.html). In
    short mod_jk URI handling created a few security holes. We didn't
    check mod_jk2 for this issue.

    For further reading, see
    http://tomcat.apache.org/connectors-doc/reference/apache.html
    particularly the ForwardURIxxx directives.

    HTH,

    Mark

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

    --
    _________________________________________________
    Jacob Rhoden
    Application Architect
    Systems Development and Integration
    University of Melbourne

    Phone: +61 3 8344 2884



    ---------------------------------------------------------------------
    To start a new topic, e-mail: users@tomcat.apache.org
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • TimJowers at Oct 26, 2007 at 1:11 pm
    Jacob Rhoden <jacob <at> rhoden.id.au> writes:

    Did you figure this out?

    It is due to a spurious extra %> at the end of a link. E.g.
    <td>
    <iframe width="900" height="700" src="bugger.jsp?c=<%=ch%>&s=<%=sh%> %>">
    </iframe>
    </td>

    Notice the programmer typed %> %> when meant %>.

    The error message:
    WARNING: Parameters: Character decoding failed. Parameter skipped.
    java.io.CharConversionException: EOF
    at org.apache.tomcat.util.buf.UDecoder.convert(UDecoder.java:83)
    at org.apache.tomcat.util.buf.UDecoder.convert(UDecoder.java:49)
    at org.apache.tomcat.util.http.Parameters.urlDecode(Parameters.java:412)

    at org.apache.tomcat.util.http.Parameters.processParameters(Parameters.j
    ava:394)
    at org.apache.tomcat.util.http.Parameters.processParameters(Parameters.j
    ava:510)
    at org.apache.tomcat.util.http.Parameters.handleQueryParameters(Paramete
    rs.java:267)
    at org.apache.catalina.connector.Request.parseParameters(Request.java:24
    21)
    at org.apache.catalina.connector.Request.getParameter(Request.java:1040)

    at org.apache.catalina.connector.RequestFacade.getParameter(RequestFacad
    e.java:355)
    at org.apache.jsp.buggershowURL_jsp._jspService(buggershowURL_jsp.java:5
    7)
    at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)

    sorta hides the real problem of a malformed URL. Maybe a good case for a nested
    Exception message. Or just don't make typos and the problem will not occur.


    ---------------------------------------------------------------------
    To start a new topic, e-mail: users@tomcat.apache.org
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Bill Barker at Oct 25, 2007 at 2:03 am
    Well, what it means is that Tomcat saw a '%' character in either the query
    string or the POST body that wasn't followed by two two hex digits (0-9
    union a-f). It is possible that it is simply a character encoding problem,
    but there isn't enough info here to really say what the problem is.

    "Jacob Rhoden" <jacob@rhoden.id.au> wrote in message
    news:471FDF89.3080005@rhoden.id.au...
    Hi,

    We are having an elusive issue on one of our production servers using
    Tomcat 6.0.14, every few minutes we are getting a request that results in
    the following exception:

    Oct 25, 2007 12:04:23 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:88)
    at org.apache.tomcat.util.buf.UDecoder.convert(UDecoder.java:49)
    at
    org.apache.tomcat.util.http.Parameters.urlDecode(Parameters.java:412)
    at
    org.apache.tomcat.util.http.Parameters.processParameters(Parameters.java:394)
    at
    org.apache.tomcat.util.http.Parameters.processParameters(Parameters.java:346)
    at
    org.apache.catalina.connector.Request.parseParameters(Request.java:2470)
    at
    org.apache.catalina.connector.Request.getParameter(Request.java:1040)
    at
    org.apache.catalina.connector.RequestFacade.getParameter(RequestFacade.java:355)
    ......

    Has anyone seen anything like this before, and know how to handle it? It
    appears Firefox 2.0.0.8 browsers and IE browsers are both passing POST
    commands that are resulting in this exception.

    A quick search on google reveals a bunch of other people who dont know
    what it is, and well, the source code that throws the exception.

    Best Regards,
    Jacob

    --
    _________________________________________________
    Jacob Rhoden
    Application Architect
    Systems Development and Integration
    University of Melbourne

    Phone: +61 3 8344 2884



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



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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupusers @
categoriestomcat
postedOct 25, '07 at 12:10a
activeOct 26, '07 at 1:11p
posts10
users4
websitetomcat.apache.org
irc#tomcat

People

Translate

site design / logo © 2018 Grokbase