commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rory Winston (JIRA)" <>
Subject [jira] Closed: (NET-290) DotTerminatedMessageReader does not parse \r \r \n correctly
Date Mon, 08 Mar 2010 10:16:27 GMT


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:
>             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
> 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.

View raw message