[
https://issues.apache.org/jira/browse/NET-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rory Winston closed NET-290.
----------------------------
Resolution: Fixed
Fix Version/s: 2.1
Thanks Jonathan - well spotted and fix applied.
> 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
> Fix For: 2.1
>
>
> 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.
