client
Click on the red underlined text to get to the source
... many years. The others are new.
These commands allow a client to restart an interrupted transfer in
transfer modes not previously supported in any documented way, and to
...
... NVFS) is also
defined, allowing servers that support such a structure to convey
that information to clients in a standard way, thus allowing clients
more certainty in constructing and interpreting pathnames.
...
... defined, allowing servers that support such a structure to convey
that information to clients in a standard way, thus allowing clients
more certainty in constructing and interpreting pathnames.
...
... server-FTP is permitted.
Clients that desire some form of pattern matching functionality must
obtain a listing of the relevant directory, or directories, and
implement their own file name selection procedures.
...
... not considered here. A server-FTP process should always use the same
time reference, so the times it returns will be consistent. Clients
are not expected to be time synchronized with the server, so the
possible difference in times that might be reported by the different
...
... immediately after. No examples here show data transferred over a
data connection from the client to the server. In all cases, the
prefixes shown above, including the one space, have been added for
...
... prefixes shown above, including the one space, have been added for
the purposes of this document, and are not a part of the data
exchanged between client and server.
...
... 3]. The presence of the 550 error response to a SIZE
command MUST NOT be taken by the client as an indication that the
file cannot be transferred in the current MODE and TYPE. A server
may generate this error for other reasons -- for instance if the
...
... REST command is intended to complete a failed transfer. Use with
RETR is comparatively well defined in all cases, as the client bears
the responsibility of merging the retrieved data with the partially
retrieved file. It may choose to use the data obtained other than to
...
... retrieved before. With STOR, however, the server must insert the
data into the file named. The results are undefined if a client uses
REST to do other than restart ...
... characters. Such a name is not illegal however, and may be
defined by the server for any purpose that suits it. Clients
implementing this specification should not assume any semantics
...
... case (where it exists) of the characters that make up file,
directory, and pathnames may be significant. Unless determined
otherwise by means unspecified here, clients should assume that
all such names are comprised of characters whose case is
significant. Servers are free to treat case (or any other
...
... anything after "TVFS" in the TVFS feature line. Clients, however,
should be prepared to deal with arbitrary text following the four
defined characters, and simply ignore it if unrecognized.
...
... error-response. For this
purpose, the parameter should be considered to be invalid if the
client issuing the command does not have permission to perform the
requested operation.
...
... octets of data in the file.
Given limitations in some systems, Client-FTP implementations must
understand this size may not be precise and may change between the
...
... RETR operation.
Clients that need highly accurate size information for some
particular reason should use the SIZE command as defined in section
4. The most common need for this accuracy is likely to be in
...
... generally not be widely understood, server-PIs should be aware that
clients will typically ignore any local facts provided. As there is
no registration of locally defined facts, it is entirely possible
...
... The following examples are all taken from dialogues between existing
FTP clients and servers. Because of this, not all possible
variations of possible response formats are shown in the examples.
...
... connection, or were not,
in fact, actually used in the examples before editing. Note also
that the formats shown are those that are transmitted between client
and server, not formats that would normally ever be reported to the
user of the client.
...
... that the formats shown are those that are transmitted between client
and server, not formats that would normally ever be reported to the
user of the client.
...
... S> 250 End
The client first asked to be told the current directory of the
server. This was purely for the purposes of clarity of this example.
The client ...
... client first asked to be told the current directory of the
server. This was purely for the purposes of clarity of this example.
The client then requested facts about a specific file. The server
returned the "250-" first control-response line, followed by a single
line of facts about the file, followed by the terminating "250 "
...
... bytes, though more or less than that may be transferred if the file
is retrieved, and a different number may be required to store the
file at the client's file store, and the connected user has
permission to retrieve the file but not to do anything else
particularly interesting.
...
... between that for "bar" and "file5". Though it is not possible to
easily represent it in this document, that shows a file with a name
comprising exactly three spaces (" "). A client will have no
difficulty determining that name from the output presented to it
however. The directory "empty" is, as its name implies, empty,
...
... Note first that the "MLSD" command, shown here as "MlsD" is case
independent. Clients may issue this command in any case, or
combination of cases, they desire. This is the case for all FTP
commands.
...
... pathnames in a case independent manner. The server seems to return
files using the case in which they were requested, when the name was
sent by the client, and otherwise uses an algorithm known only to
itself to select the case of the names it returns.
...
... of which it will send by default. It also supports two OS dependent
facts, and one locally defined fact. The latter three must be
requested expressly by the client for this server to supply them.
C> Feat
...
...
For the MLSx commands, the Client-FTP may specify a list of facts it
wishes to be returned in all subsequent MLSx ...
...
By sending the "OPTS MLST" command, the client requests the server to
include only the facts listed as arguments to the command in
subsequent output from MLSx ...
... listed should simply be omitted from the MLSx output. This is not an
error. Note that where no factname arguments are present, the client
is requesting that only the file names be returned. In this case,
and in any other case where no facts are included in the result, the
...
... immediately thereafter.
Clients should note that generating values for some facts can be
possible, but very expensive, for some servers. It is generally
acceptable to retrieve any of the facts that the server offers as its
...
... default set before any "OPTS MLST" command has been given, however
clients should use particular caution before requesting any facts not
in that set. That is, while other facts may be available from the
server, clients ...
... clients should use particular caution before requesting any facts not
in that set. That is, while other facts may be available from the
server, clients should refrain from requesting such facts unless
there is a particular operational requirement ...
... initial default feature output for MLST. The facts requested are
then changed by the client. The first change shows facts that are
available from the server being selected. Subsequent FEAT output
...
... available from the server being selected. Subsequent FEAT output
shows the altered features as being returned. The client then
attempts to select some standard features that the server does not
support. This is not an error, however the server simply ignores the
...
... requests for unsupported features, as the FEAT output that follows
shows. Then, the client attempts to request a non-standard, and
unsupported, feature. The server ignores that, and selects only the
supported features requested. Lastly, the client ...
... client attempts to request a non-standard, and
unsupported, feature. The server ignores that, and selects only the
supported features requested. Lastly, the client sends a request
containing a syntax error (spaces cannot appear in the factlist.)
...
... authentication has occurred [6]. This allows unauthenticated clients
to determine which of the features defined here are supported, and to
negotiate the fact list for MLSx ...
...
All of the examples in this document are taken from actual
client/server exchanges, though some have been edited for brevity, or
to meet document formatting requirements.
...