Where a server-FTP process does not support the FEAT command, it will
respond to the FEAT command with a 500 or 502 reply. This is simply
the normal "unrecognized command" reply that any unknown command
would elicit. Errors in the command syntax, such as giving
parameters, will result in a 501 reply.
Server-FTP processes that recognize the FEAT command, but implement
no extended features, and therefore have nothing to report, SHOULD
respond with the "no-features" 211 reply. However, as this case is
practically indistinguishable from a server-FTP that does not
recognize the FEAT command, a 500 or 502 reply MAY also be used. The
"no-features" reply MUST NOT use the multi-line response format,
exactly one response line is required and permitted.
Replies to the FEAT command MUST comply with the following syntax.
Text on the first line of the reply is free form, and not
interpreted, and has no practical use, as this text is not expected
to be revealed to end users. The syntax of other reply lines is
precisely defined, and if present, MUST be exactly as specified.
feat-response = error-response / no-features / feature-listing
no-features = "211" SP *TCHAR CRLF
feature-listing = "211-" *TCHAR CRLF
1*( SP feature CRLF )
"211 End" CRLF
feature = feature-label [ SP feature-parms ]
feature-label = 1*VCHAR
feature-parms = 1*TCHAR
Note that each feature line in the feature-listing begins with a
single space. That space is not optional, nor does it indicate
general white space. This space guarantees that the feature line can
never be misinterpreted as the end of the feature-listing, but is
required even where there is no possibility of ambiguity.
Each extension supported must be listed on a separate line to
facilitate the possible inclusion of parameters supported by each
extension command. The feature-label to be used in the response to
the FEAT command will be specified as each new feature is added to
the FTP command set. Often it will be the name of a new command
added, however this is not required. In fact it is not required that
a new feature actually add a new command. Any parameters included
are to be specified with the definition of the command concerned.
That specification shall also specify how any parameters present are
to be interpreted.
The feature-label and feature-parms are nominally case sensitive,
however the definitions of specific labels and parameters specify the
precise interpretation, and it is to be expected that those
definitions will usually specify the label and parameters in a case
independent manner. Where this is done, implementations are
recommended to use upper case letters when transmitting the feature
response.
The FEAT command itself is not included in the list of features
supported, support for the FEAT command is indicated by return of a
reply other than a 500 or 502 reply.
A typical example reply to the FEAT command might be a multiline
reply of the form:
C> feat
S> 211-Extensions supported:
S> MLST size*;create;modify*;perm;media-type
S> SIZE
S> COMPRESSION
S> MDTM
S> 211 END
The particular extensions shown here are simply examples of what may
be defined in other places, no particular meaning should be
attributed to them. Recall also, that the feature names returned are
not command names, as such, but simply indications that the server
possesses some attribute or other.
The order in which the features are returned is of no importance,
server-FTP processes are not required to implement any particular
order, or even to consistently return the same order when the command
is repeated.
FTP implementations which support FEAT MUST include in the response
to the FEAT command all properly documented FTP extensions beyond
those commands and mechanisms described in
RFC959 [1], including any
which existed before the existence of FEAT. That is, when a client
receives a FEAT response from an FTP server, it can assume that the
only extensions the server supports are those that are listed in the
FEAT response.
User-FTP processes should, however, be aware that there have been
several FTP extensions developed, and in widespread use, prior to the
adoption of this document and the FEAT command. The effect of this
is that an error response to the FEAT command does not necessarily
imply that those extensions are not supported by the server-FTP
process. User-PIs should test for such extensions individually if an
error response has been received to the FEAT command.
原文地址:
http://www.faqs.org/rfcs/rfc2389.html
