[NET-290] DotTerminatedMessageReader does not parse \r \r \n correctly

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 2.0
• Fix Version/s: 2.2

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)

• Assignee: Unassigned
• Reporter: Jonathan Baker
• Created: 19/Aug/09 19:08
• Updated: 15/Oct/10 09:20
• Resolved: 08/Mar/10 10:15

Description

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 ); > }