1#@!#!123s

��JFIF�� 1#@!#!123s
: / usr / share / doc / proftpd-doc / howto /
Filename : ASCII.html
back
<!DOCTYPE html>
<html>
<head>
<title>ProFTPD: ASCII Transfers</title>
</head>

<body bgcolor=white>

<hr>
<center><h2><b>ProFTPD: ASCII Transfers</b></h2></center>
<hr>

<p>
Like most FTP servers (and clients), <code>proftpd</code> contains code
specifically for handling files that are transferred in ASCII mode.
<a href="http://www.faqs.org/rfcs/rfc959.html">RFC959</a> requires that when
sending a file transferred in ASCII mode, the server (or client) <b>must</b>
ensure that every carriage return (CR) character is followed by a line feed
(LF) character.  The receiving program then checks the file for these CRLF
sequences and re-translates them into the native line-ending format for the
host machine.  This allows clients on platforms whose ASCII line ending is
CRLF (<i>e.g.</i> Windows) to send those files to platforms whose ASCII line
ending is LF (<i>e.g.</i> Unix), at the cost of complex handling of ASCII
data in FTP.

<p>
The FTP <code>TYPE</code> command is used by the client to tell the server
which transfer type is to be used: <code>A</code> for ASCII, <code>I</code>
for binary.  For the <code>LIST</code> and <code>NLST</code> FTP commands,
the data transfer is <i>always</i> done in ASCII mode.  The other FTP
commands are unaffected by the transfer mode, with two notable exceptions:
<code>REST</code> and <code>SIZE</code>.

<p>
Why should <code>REST</code> (for resuming a transfer) and <code>SIZE</code>
(for determining the size of a file on the server) be affected?  The
<code>REST</code> command tells the server at which byte to begin transferring
a file.  Recall that since the server may have altered the bytes received
from the client in ASCII mode, the offset used by the client may be in
a different position of the file on the server.  Similarly, in ASCII mode,
the size of the file that the client will receive may be different than
the actual size of the file on the server.  For example, a Unix FTP server
transferring a file in ASCII mode to a Windows FTP client will need to add
CR characters, increasing the size of the file (from the server's point of
view).

<p>
Properly handling the <code>SIZE</code> command would require the server to
scan the file in question and perform the translation logic, which is
resource-intensive.  It is an easy way for a malicious client to try a
&quot;denial of service&quot; attack on the server, forcing the server to
perform many time-consuming calculations needlessly.  The <code>REST</code>
command can be abused in the same fashion.  ProFTPD thus <b>does not</b>
perform ASCII translation when handling the <code>REST</code> and
<code>SIZE</code> commands.

<p>
An FTP client will usually use <code>SIZE</code> when it wants to resume
downloading file.  However, clients in general should not be resuming downloads
in ASCII mode.  Resuming downloads in binary mode is the recommended way.

<p><a name="FAQ">
<b>Frequently Asked Questions</b>

<p>
<font color=red>Question</font>: The <code>SIZE</code> <i>used</i> to work,
regardless of the ASCII/binary mode, in 1.2.10.  Why was it changed?<br>
<font color=blue>Answer</font>: The restriction on the <code>SIZE</code>
command first appeared in 1.3.0rc1.

<p>
Prior to the restriction, the file size reported by <code>proftpd</code>
via <code>SIZE</code> did not take into account any possible CRLF translation
(as mandated by RFC959 for ASCII mode transfers); this means that the
reported size could be misleading.  The reported size might not match the
actual number of bytes that a client might download.  Now, <code>proftpd</code>
would rather provide no answer at all to a <code>SIZE</code> over providing
a wrong answer.

<p>
<hr>
<font size=2><b><i>
&copy; Copyright 2017 The ProFTPD Project<br>
 All Rights Reserved<br>
</i></b></font>
<hr>

</body>
</html>