Jetty
  1. Jetty
  2. JETTY-195

Typo in AJP13Connector log message

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Trivial Trivial
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:
      N/A
    • Number of attachments :
      1

      Description

      http://jetty.mortbay.org/xref/org/mortbay/jetty/ajp/Ajp13Parser.html#270

      Log.warn("AJP13 message type ({}) not supported/regonised as a "+"container request",Integer.toString(packetType));

      s/regonised/recognised/ ?

        Activity

        Hide
        Russell Howe added a comment -

        tcpdump trace produced by:

        tcpdump -w ajp13.trace -s 65535 -ni eth0 port 8009 and host 192.168.0.104

        192.168.0.104 is Jetty 6.1.0rc2
        192.168.0.6 is apache-ssl 1.3.x from Debian sarge

        Show
        Russell Howe added a comment - tcpdump trace produced by: tcpdump -w ajp13.trace -s 65535 -ni eth0 port 8009 and host 192.168.0.104 192.168.0.104 is Jetty 6.1.0rc2 192.168.0.6 is apache-ssl 1.3.x from Debian sarge
        Hide
        Russell Howe added a comment -

        I thought I'd take a stab at dissecting this...
        I think the parser might be tripping over the AJP13 ssl_cipher attribute (attribute type 0x08) in the AJP request.

        Looking at the packet dump, we have (packet #4, offset 0x2f9) the following byte sequence:

        08 00 0a 41 45 53 32 35 36 2d 53 48 41 00 ff

        Which translates to something like:

        {ajp13 request attribute ssl_cipher 0x08} {null terminator 0x00} {ajp13 request attribute value marker 0x0a} "AES256-SHA" {null terminator 0x00} {ajp13 end of attributes marker 0xff }

        From the somewhat cryptic and apparently reverse-engineered ajp13 spec at http://tomcat.apache.org/connectors-doc-archive/jk2/common/AJPv13.html#Request%20Packet%20Structure
        it looks to me like this is saying:

        ssl_cipher name "" has value "AES256-SHA"
        end-of-attributes

        Does the 0x00 immediately after the 0x08 indicate that the 'key' part of the ssl_cipher key-value pair is the empty string? Is the AJP13 parser failing to handle this case?

        Show
        Russell Howe added a comment - I thought I'd take a stab at dissecting this... I think the parser might be tripping over the AJP13 ssl_cipher attribute (attribute type 0x08) in the AJP request. Looking at the packet dump, we have (packet #4, offset 0x2f9) the following byte sequence: 08 00 0a 41 45 53 32 35 36 2d 53 48 41 00 ff Which translates to something like: {ajp13 request attribute ssl_cipher 0x08} {null terminator 0x00} {ajp13 request attribute value marker 0x0a} "AES256-SHA" {null terminator 0x00} {ajp13 end of attributes marker 0xff } From the somewhat cryptic and apparently reverse-engineered ajp13 spec at http://tomcat.apache.org/connectors-doc-archive/jk2/common/AJPv13.html#Request%20Packet%20Structure it looks to me like this is saying: ssl_cipher name "" has value "AES256-SHA" end-of-attributes Does the 0x00 immediately after the 0x08 indicate that the 'key' part of the ssl_cipher key-value pair is the empty string? Is the AJP13 parser failing to handle this case?
        Hide
        Greg Wilkins added a comment -

        The really strange thing is that even wireshark is not decoding this attribute correctly??
        investigating....

        Show
        Greg Wilkins added a comment - The really strange thing is that even wireshark is not decoding this attribute correctly?? investigating....
        Hide
        Greg Wilkins added a comment -

        OK - I have fixed this bit (in svn now). It was simply that the 0x08 handling had not been implemented, so
        the length was being handled as the next attribute... which it was not!

        thanks for the trace - made it very easy.

        are all aspects of this issue fixed now?

        Show
        Greg Wilkins added a comment - OK - I have fixed this bit (in svn now). It was simply that the 0x08 handling had not been implemented, so the length was being handled as the next attribute... which it was not! thanks for the trace - made it very easy. are all aspects of this issue fixed now?
        Hide
        Russell Howe added a comment -

        Thanks Greg.

        This issue, the typo, was fixed a while back. The issue you fixed (which is really JETTY-196) looks good to me - I can now use Jetty behind apache-ssl 1.3.x and mod_jk.

        getRemoteHost() is still acting up for me when using the Ajp13Connector, however. I'm still getting the address of the Apache server returned by HttpServletRequest.getRemoteHost() when the request comes into Jetty via Ajp13. See JETTY-197 for that

        Show
        Russell Howe added a comment - Thanks Greg. This issue, the typo, was fixed a while back. The issue you fixed (which is really JETTY-196 ) looks good to me - I can now use Jetty behind apache-ssl 1.3.x and mod_jk. getRemoteHost() is still acting up for me when using the Ajp13Connector, however. I'm still getting the address of the Apache server returned by HttpServletRequest.getRemoteHost() when the request comes into Jetty via Ajp13. See JETTY-197 for that

          People

          • Assignee:
            Leopoldo Agdeppa III
            Reporter:
            Russell Howe
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: