net.sf.hermesftp.cmd.impl
Class FtpCmdFeat

java.lang.Object
  net.sf.hermesftp.cmd.AbstractFtpCmd
      net.sf.hermesftp.cmd.impl.FtpCmdFeat

All Implemented Interfaces:

java.lang.Cloneable, FtpCmd, FtpConstants

public class FtpCmdFeat
extends AbstractFtpCmd

FEAT Command

It is not to be expected that all servers will necessarily support all of the new commands defined in all future amendments to the FTP protocol. In order to permit clients to determine which new commands are supported by a particular server, without trying each possible command, one new command is added to the FTP command repertoire. This command requests the server to list all extension commands, or extended mechanisms, that it supports. That is, all defined and specified commands and features not defined in [1], or this document, must be included in the FEAT command output in the form specified in the document that defines the extension.

User-FTP PIs must expect to see, in FEAT command responses, unknown features listed. This is not an error, and simply indicates that the server-FTP implementor has seen, and implemented, the specification of a new feature that is unknown to the user-FTP.

The FEAT command consists solely of the word "FEAT". It has no parameters or arguments.

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.

While not absolutely necessary, a standard mechanism for the server- PI to inform the user-PI of any features and extensions supported will help reduce unnecessary traffic between the user-PI and server- PI as more extensions may be introduced in the future. If no mechanism existed for this, a user-FTP process would have to try each extension in turn resulting in a series of exchanges between the user-PI and server-PI. Apart from being possibly wasteful, this procedure may not always be possible, as issuing of a command just to determine if it is supported or not may have some effect that is not desired. *

[Excerpt from RFC-2389, Hethmon and Elz]

Author:

Lars Behnke

Field Summary

Fields inherited from interface net.sf.hermesftp.common.FtpConstants

ATTR_CLIENT_NAME, ATTR_DATA_PROT, ATTR_FILE_OFFSET, ATTR_FORCE_UTF8, ATTR_GROUP_DATA, ATTR_LOGIN_TIME, ATTR_RENAME_FILE, ATTR_RESTART_MARKERS, ATTR_SSL, ATTR_USER_DATA, BYTE_LENGTH, BYTE_MASK, DEFAULT_BEAN_RES, DEFAULT_KEYSTORE, DEFAULT_KEYSTORE_PASS, DT_ASCII, DT_BINARY, DT_EBCDIC, HERMES_HOME, MILLI, MODE_BLOCK, MODE_COMPRESS, MODE_STREAM, MODE_ZIP, MSG_GOODBYE, MSG150, MSG200, MSG200_NOTED, MSG200_PBSZ, MSG200_SIZE, MSG200_TYPE, MSG202, MSG211_FEAT_ENTRY, MSG211_FEAT_FOOTER, MSG211_FEAT_HEADER, MSG211_STAT, MSG213_SIZE, MSG213_TIME, MSG214, MSG220, MSG220_WEL, MSG226, MSG227, MSG229, MSG230, MSG234, MSG250, MSG257, MSG331, MSG350, MSG350_REST, MSG421, MSG425, MSG426, MSG431, MSG450, MSG451, MSG500, MSG500_CMD, MSG501, MSG501_PATH, MSG501_SIZE, MSG503, MSG503_USR, MSG504, MSG522, MSG530, MSG530_AUTH, MSG534, MSG536, MSG550, MSG550_COMM, MSG550_EXISTS, MSG550_MSG, MSG550_NOTEMPTY, MSG550_PERM, MSG553, OPT_ALLOWED_PASSIVE_PORTS, OPT_BUFFER_SIZE, OPT_CHARSET_ASCII, OPT_CHARSET_EBCDIC, OPT_EMULATE_UNIX, OPT_FTP_PORT, OPT_IPV4_BLACK_LIST, OPT_IPV6_BLACK_LIST, OPT_MAX_CONNECTIONS, OPT_MAX_DOWNLOAD_RATE, OPT_MAX_IDLE_SECONDS, OPT_MAX_UPLOAD_RATE, OPT_MSG_GOODBYE, OPT_MSG_WELCOME, OPT_REMOTE_DIR, OPT_SSL_ALLOW_EXPLICIT, OPT_SSL_ALLOW_IMPLICIT, OPT_SSL_CIPHER_SUITES, OPT_SSL_FORCE, OPT_SSL_KEYSTORE_FILE, OPT_SSL_KEYSTORE_PASS, OPT_SSL_PORT_IMPLICIT, PRIV_NONE, PRIV_READ, PRIV_READ_WRITE, PRIV_WRITE, PWD, SEPARATOR, SERVER_STATUS_HALTED, SERVER_STATUS_INIT, SERVER_STATUS_READY, SERVER_STATUS_UNDEF, SPACE, STAT_BYTES_DOWNLOADED, STAT_BYTES_UPLOADED, STAT_DOWNLOAD_RATE, STAT_FILES_DOWNLOADED, STAT_FILES_UPLOADED, STAT_UPLOAD_RATE, STRUCT_FILE, STRUCT_RECORD, TYPE_NAMES, WILDCARD

Constructor Summary

FtpCmdFeat()

Method Summary

void	execute() Executes the command.
java.lang.String	getHelp() Returns a short help text for the command.
boolean	isAuthenticationRequired() Returns whether authentication is needed or not.

Methods inherited from class net.sf.hermesftp.cmd.AbstractFtpCmd

getAbsPath, getAndResetFileOffset, getArguments, getCtx, getPathArg, getPermission, getToken, handleAsyncCmd, isResponded, msg, msg, msg, msgOut, msgOut, msgOut, out, setArguments, setCtx, setToken

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Constructor Detail

FtpCmdFeat

public FtpCmdFeat()

Method Detail

execute

public void execute()
             throws FtpCmdException

Executes the command.

Throws:

FtpCmdException - Thrown on any exception occuring while the command is executed.

getHelp

public java.lang.String getHelp()

Returns a short help text for the command.

Returns:

The help text.

isAuthenticationRequired

public boolean isAuthenticationRequired()

Returns whether authentication is needed or not.

Returns:

True, if the command requires authentication.