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.
