home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!olivea!decwrl!pa.dec.com!ninja!zowie.zso.dec.com!ridder
- From: ridder@zso.dec.com (Hans Ridder)
- Newsgroups: comp.protocols.tcp-ip
- Subject: Problem with ASCII mode FTP
- Message-ID: <1992Jul28.185832.1348@ninja.zso.dec.com>
- Date: 28 Jul 92 18:58:32 GMT
- Sender: news@ninja.zso.dec.com (USENET News System)
- Organization: Digital Equipment Corporation - DECwest Engineering
- Lines: 26
- Originator: ridder@zowie.zso.dec.com
- Nntp-Posting-Host: zowie.zso.dec.com
-
- I have a question regarding the use of CR/NUL sequences in ASCII mode
- FTP transfers. One particular PC implementation of FTP, when sending,
- is converting a bare CR (intending to "overprint") into a CR/NUL. When
- received by the ftpd on Ultrix, the NUL is not stripped. This NUL then
- causes a problem when the file is printed, but that's another issue.
-
- Checking the FTP RFC, it says that ASCII mode should use the TELNET NVT
- protocol. The TELNET RFC says that bare CR's should never appear in the
- data stream, that when sending they should be converted to CR/NUL, and
- back to local format on receive. The FTP RFC talks quite a bit about
- various aspects of CR/LF processing, but never mentions CR/NUL.
-
- From all this reading, I conclude that the Ultrix ftpd (and possibly
- ftp) is broken, and should be stripping the NUL. Checking the source
- code revealed there is code to strip the NUL, but it is #ifdef'd out.
- Are all BSD derived implementations the same?
-
- Should this ftpd be stripping the NUL following the CR, or not? I say
- yes, however I wanted to check with all you for any folklore and
- opinions on the issue. Thanks!
-
- -hans
- --
- Hans-Gabriel Ridder Digital DECwest Engineering
- ridder@rust.zso.dec.com Bellevue, Washington, USA
- {pacbell,pyramid,uunet}!rust.zso.dec.com!ridder
-