Uploaded image for project: 'Commons Net'
  1. Commons Net
  2. NET-290

DotTerminatedMessageReader does not parse \r \r \n correctly

VotersWatch issueWatchersLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments


    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 2.0
    • 2.2
    • None
    • None


      If the DotTerminatedMessageReader receives two carriage return characters at the end of the line, it does not process them correctly.

      When the DTMR tries to read "\r\r\n" from the server, it does not process this as a correct end of line. The code handles the first \r as a standalone character, but then does not process the second \r character to test for end-of-line. If this happens at the end of a file, the DTMR will not recognize the '.' character as the end of file, and will try to read another character. This hangs the reader.

      The process flow breaks down in the following order. The first \r character is tested at line 127. It then reads the second \r character at line 133. The test fails, and the second \r is pushed in to the internalBuffer at line 160. The second time the read() method is called, the \r character is returned without processing at line 90. The third time the read() is called, the \n character is read and checked at line 127. But, because the preceding \r character is not found first, it does not process this as EOL. If the next character is a '.', it is not processed as EOF.

      The following fix solves the problem by pushing the second \r character back in to the reader stream (rather than putting it in the internalBuffer), where it will be processed correctly:

      > else if ( ch == '\r' )

      { > internalReader.unread( ch ); > }



          This comment will be Viewable by All Users Viewable by All Users


            Unassigned Unassigned
            jonebaker Jonathan Baker
            0 Vote for this issue
            1 Start watching this issue




                Issue deployment