ftp_readline() violates RFC 959 (end-of-line handling)

This bug report refers to ext/ftp/ftp.c, version 1.23. According to RFC 959, section 4.2, "A reply is defined to contain the 3-digit code, followed by Space <SP>, followed by one line of text [...], and terminated by the Telnet end-of-line code." Although it seems as if other end-of-line definitions may have been possible (or at least anticipated) under certain circumstances (see section 4.2, page 34), RFC 2640, section 3.1 makes it clear that end-of-line corresponds to CRLF and that individual occurrences of CR and LF are completely legal, so treating LF as a line terminator ... else if (*eol == '\n') { *eol = 0; ... seems like a Bad Idea. (There are other issues, e.g. related to the NUL character, that probably need to be addressed eventually.) Now, if a server's response includes an individual CR, the following code segment of ftp_readline() ... if (*eol == '\r') { *eol = 0; ftp->extra = eol + 1; if (rcvd > 1 && *(eol + 1) == '\n') { ftp->extra++; rcvd--; } ... will cause the (incomplete) status line to be returned prematurely to ftp_getresp(), followed by another line containing the remainder. As ftp_getresp() does not even check whether the line returned by ftp_readline() contains at least four characters ... if (!ftp_readline(ftp)) return 0; if (ftp->inbuf[3] == '-') continue; else if (ftp->inbuf[3] != ' ') return 0; ... before interpreting the character after the three-digit result code, this may cause unpredictable behavior, e.g. in the event of CRCRLF. Please note that it is _not_ sufficient to simply check whether the character following the CR is a LF, as the LF may not arrive until the _next_ time my_recv() is called. Kind regards Ralph (not subscribed to php-dev, so CC me if you feel the need)