commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Baker (JIRA)" <j...@apache.org>
Subject [jira] Created: (NET-290) DotTerminatedMessageReader does not parse \r \r \n correctly
Date Wed, 19 Aug 2009 19:10:14 GMT
DotTerminatedMessageReader does not parse \r \r \n correctly
------------------------------------------------------------

                 Key: NET-290
                 URL: https://issues.apache.org/jira/browse/NET-290
             Project: Commons Net
          Issue Type: Bug
    Affects Versions: 2.0
         Environment: RedHat Linux
Linux XXX 2.6.18-128.2.1.el5 #1 SMP Wed Jul 8 11:54:47 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0"
OpenJDK  Runtime Environment (build 1.6.0-b09)
OpenJDK 64-Bit Server VM (build 1.6.0-b09, mixed mode)

            Reporter: Jonathan Baker


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:

160a160,163
>                 else if ( ch == '\r' )
>                 {
>                       internalReader.unread( ch );
>                 }


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message