RFC: 959
Statut : Standard
Retour à l'index des normes : INDEX FRANCAIS

Remplace RFC: 765 (IEN 149)

File Transfer Protocol (FTP)

Spécification


Crédits : J. Postel, J. Reynolds / ISI
Traduction : Valéry G. FREMAUX Ingénieur Professeur / EISTI
Edition originale : Octobre 1985 / Version FR: Février 1997

Précédent - Suite - Retour au sommaire


5. SPECIFICATIONS DECLARATIVES

5.1. IMPLEMENTATION MINIMALE

Afin de rendre FTP exploitable sans multiplication de messages d'erreur inutiles, une implémentation minimale à assurer par tous serveurs est définie ci-après :

TYPE - ASCII Non-print

MODE - Flux

STRUCTURE - Fichier, Enregistrement

COMMANDES - USER, QUIT, PORT,

TYPE, MODE, STRU, pour les valeurs par défaut

RETR, STOR,

NOOP.

Les paramètres par défaut pour le transfert de données sont :

TYPE - ASCII Non-print

MODE - Stream

STRU - File

Tous les hôtes doivent accepter les paramètres ci-dessus comme paramètres par défaut standards.

5.2. CONNEXIONS

L'interpréteur de protocole serveur "écoute" sur le Port L. L'utilisateur, ou son interpréteur de protocole doit prendre l'initiative de l'établissement de la connexion bidirectionnelle du canal de contrôle. Les processus SERVER- et USER- doivent suivre les conventions du protocole Telnet spécifiées dans le ARPA-Internet Protocol Handbook [1]. Les serveurs n'ont aucune obligation de fournir un moyen d'éditer la ligne de commande. Cette édition, si nécessaire, peut être déléguée au processus utilisateur. La connexion de contrôle pourra être coupée par le serveur sur demande de l'utilisateur, après conclusion de toutes les transmissions de commandes et réponses associées.

Le USER-DTP doit "écouter" le Port de données spécifié; celui-ci peut être le port standard (U) ou le port donnée par une commande PORT. Le serveur peut lui-même établir la connexion du canal de données entre son port de données standard (L-1) et le port utilisateur spécifié. Le port utilisé, et le sens de transfert seront déterminés par la nature de la commande de service FTP à exécuter.

Notez que toutes les implémentations FTP doivent pouvoir piloter des transferts sur le port de données par défaut, alors que seuls les USER-PI peuvent provoquer l'usage des ports non standard.

Lorsque des données doivent être transmises entre deux serveurs, A et B (voir Figure 2), le USER-PI de C établit un canal de contrôle avec chacun des SERVER-PI de A et respectivement de B. L'un des serveurs, disons A, reçoit une commande PASV lui indiquant "d'écouter" son port de données plutôt que tenter une connexion lorsqu'il reçoit un ordre de transfert. Lorsque le USER-PI reçoit l'acquittement de cette commande PASV, qui inclut l'identité et le port du serveur "écouté", le USER-PI envoie la référence au port A au serveur B par une commande PORT; une réponse est attendue. Le USER-PI émet alors les commandes de service FTP correspondantes à A et à B. Le serveur B établit la connexion de données et le transfert commence. La séquence de commandes est montrée ci-dessous (les messages sont explicités selon un synchronisme vertical, la disposition horizontale restant asynchrone) :

     USER-PI - Serveur A        USER-PI - Serveur B
     -------------------        -------------------
     
     C->A : Connect                      C->B : Connect
     C->A : PASV
     A->C : 227 Entering Passive Mode. A1,A2,A3,A4,a1,a2
                                        C->B : PORT A1,A2,A3,A4,a1,a2
                                        B->C : 200 Okay
     C->A : STOR                        C->B : RETR
                B->A : Connect to HOST-A, PORT-a
 

Figure 3

La connexion de données peut être fermée par le serveur sous les conditions décrites à la Section traitant de l'Etablissement de la Connexion de Données. Si la fermeture du canal de données survient après un transfert pour lequel la fermeture du canal ne correspond pas à une nécessité de signaler une fin-de-fichier (EOF), le serveur peut en prendre l'initiative immédiate. Il n'est pas permis d'accepter une nouvelle commande de transfert dans ce cas car le processus utilisateur ne pourra tester l'état de la connexion de données pour se mettre en écoute sur celle-ci (il l'a déjà fait une fois, et n'a pas à priori de moyen de savoir que la connexion est refermée, par contre, un utilisateur doit nécessairement pouvoir se mettre en écoute d'un canal de données "fermé" AVANT d'envoyer une commande de transfert). Pour éviter un blocage en ce point, le serveur renvoie une réponse (226) après avoir fermé le canal de données (ou, si le canal est laissé ouvert, une réponse "transfert terminé" (250)). Le USER-PI devra attendre une de ces deux réponses avant de relancer une commande de transfert

Chaque fois qu'un utilisateur ou un serveur s'aperçoit que le canal de données a été fermé à l'autre bout, il devra le plus rapidement possible vider les tampons associés à ce canal, et refermer son propre côté de ce dernier.

5.3. COMMANDES

Les commandes sont des chaînes de caractères conformes au protocole Telnet transmises sur des canaux de contrôle tel que le décrit la Section traitant des Commandes FTP. Les fonctions et sémantique des commandes sont décrites dans la Section traitant des Commandes de Contrôle d'Accès, Commandes de Paramétrage de Transfert, Commandes de Service FTP, et Commandes Diverses. La syntaxe des commandes est précisée ci-après.

Toute commande commence par un code de commande suivi d'un champ d'argument. Le code de commande est composé d'au plus quatre caractères alphabétiques. Il ne doit pas être tenu compte de la casse dans un code de commande FTP. Ainsi, toutes les combinaisons suivantes se réfèrent à la commande de téléchargement :

COLOR="#008000"> RETR Retr retr ReTr rETr

Ceci s'applique à tous les symboles utilisés pour donner les codes de valeurs des arguments, comme "A" ou "a" pour le TYPE ASCII. Le code de commande et les arguments doivent être séparés l'un l'autre par un Espace.

Le champ d'argument est une chaîne de longueur variable terminée par la séquence <CRLF> en représentation NVT-ASCII, ou la séquence de fin-de-ligne correspondante si un autre langage a été négocié pour la transmission. Il doit être noté ici que le serveur doit attendre la réception de cette séquence avant d'exécuter une quelconque action.

La syntaxe est explicitée ci-dessous en NVT-ASCII. Tous les caractères du champ d'arguments sont des caractères ASCII incluant toute représentation décimale d'entiers en ASCII. Les crochets indiquent un argument optionnel. Si cette option n'est pas explicite, la valeur par défaut est considérée.

5.3.1. COMMANDES FTP

Les commandes FTP sont spécifiées ci-dessous :

      USER <SP> <nom d'utilisateur> <CRLF>
      PASS <SP> <mot de passe> <CRLF>
      ACCT <SP> <compte utilisateur> <CRLF>
      CWD <SP> <chemin d'accès> <CRLF>
      CDUP <CRLF>
      SMNT <SP> <chemin d'accès> <CRLF>
      QUIT <CRLF>
      REIN <CRLF>
      PORT <SP> <port> <CRLF>
      PASV <CRLF>
      TYPE <SP> <code type> <CRLF>
      STRU <SP> <code structure> <CRLF>
      MODE <SP> <code mode> <CRLF>
      RETR <SP> <chemin d'accès> <CRLF>
      STOR <SP> <chemin d'accès> <CRLF>
      STOU <CRLF>
      APPE <SP> <chemin d'accès> <CRLF>
      ALLO <SP> <entier décimal>
        [<SP> R <SP> <entier décimal>] <CRLF>
      REST <SP> <marqueur> <CRLF>
      RNFR <SP> <chemin d'accès> <CRLF>
      RNTO <SP> <chemin d'accès> <CRLF>
      ABOR <CRLF>
      DELE <SP> <chemin d'accès> <CRLF>
      RMD <SP> <chemin d'accès> <CRLF>
      MKD <SP> <chemin d'accès> <CRLF>
      PWD <CRLF>
      LIST [<SP> <chemin d'accès>] <CRLF>
      NLST [<SP> <chemin d'accès>] <CRLF>
      SITE <SP> <chaîne> <CRLF>
      SYST <CRLF>
      STAT [<SP> <chemin d'accès>] <CRLF>
      HELP [<SP> <chaîne>] <CRLF>
      NOOP <CRLF>

5.3.2. ARGUMENTS DE COMMANDES FTP

Syntaxe des champs d'arguments ci-avant (notation BNF si applicable) :

<nom d'utilisateur> ::= <chaîne> <mot de passe> ::= <chaîne> <compte utilisateur> ::= <chaîne> <chaîne> ::= <char> | <char><chaîne> <char> ::= tout caractère ASCII de code 0 à 128 sauf <CR> et <LF> <marqueur> ::= <pr-chaîne> <pr-chaîne> ::= <pr-char> | <pr-char><pr-chaîne> <pr-char> ::= caractères imprimables, codes ASCII de 33 à 126 <taille d'octet> ::= <nombre> <port> ::= <adresse hôte>,<numéro port> <adresse hôte> ::= <nombre>,<nombre>,<nombre>,<nombre> <numéro port> ::= <nombre>,<nombre> <nombre> ::= tout entier décimal entre 1 et 255 <code format> ::= N | T | C <type-code> ::= A [<sp> <code format>] | E [<sp> <code format>] | I | L <sp> <taille d'octet> <code structure> ::= F | R | P <code mode> ::= S | B | C <chemin d'accès> ::= <chaîne> <entier décimal> ::= tout entier décimal codé en ASCII

5.4. SEQUENCEMENT DES COMMANDES ET REPONSES

La communication entre l'utilisateur et le serveur est prévue pour autoriser un dialogue bidirectionnel. A ce titre, l'utilisateur émet une commande FTP à laquelle le serveur répond par une première réponse rapide provisoire. L'utilisateur devra attendre cette réponse, positive ou négative, avant de pouvoir émettre une autre commande.

Certaines commandes nécessitent l'attente d'une deuxième réponse. Ces réponses peuvent, par exemple, donner un état d'avancement ou de conclusion d'un transfert de fichier ou signaler la fermeture du canal de données. Ce sont des réponses secondaires à des commandes de transfert de fichier.

Un groupe important de réponses est celui qui contient les réponses d'information suite à la conclusion d'une connexion. En des circonstances normales, un serveur émettra une réponse de code 220, "attente d'entrée", lorsque la connexion est établie. L'utilisateur devra attendre cette réponse d'état avant d'émettre toute commande. Si les serveur n'est pas immédiatement en état de recevoir des commandes, il émettra une réponse de code 120 "service retardé" immédiatement après l'établissement de la connexion, puis une réponse de code 220 dès qu'il est en état de recevoir. L'utilisateur est averti de ce temps d'attente, et pourra choisir de maintenir la connexion.

Réponses spontanées

Parfois, "le système" a spontanément un message à émettre vers l'utilisateur (en général à tous les utilisateurs connectés).Par exemple, "Arrêt du système dans 15 minutes". FTP ne propose pas de mécanisme particulier pour émettre spontanément un message du serveur vers l'utilisateur. Il est recommandé d'empiler cette réponse au niveau du SERVER-PI et de délivrer cette information lors de l'émission d'une réponse classique ultérieure (par exemple en constituant une réponse multilignes).

La table ci-après liste les réponses positives et négatives pour chaque commande. Il est demandé un respect strict des codes de réponse dans les situations indiquées; le texte émis par le serveur est libre, bien que son sens général et l'indication sur l'action à exécuter dusse rester explicite, dans le contexte, et univoque.

Séquences de Commandes Réponses

Dans cette section sont présentées les séquences usuelles de commandes-réponses. Chaque commande est listée avec toutes ses réponses possibles; les groupes de commandes sont listés ensembles. Les réponses provisoires sont listées en premier, puis les réponses définitives positives et négatives, enfin, les réponses intermédiaires avec les reste des réponses suivantes de la séquence. Ces listes sont à la base des diagrammes d'états, présentés plus en avant.

Etablissement de connexion

        120
        220
        220
        421

Ouverture de session

        USER
         230
         530
         500, 501, 421
         331, 332
        PASS
         230
         202
         530
         500, 501, 503, 421
         332
        ACCT
         230
         202
         530
         500, 501, 503, 421
        CWD
         250
         500, 501, 502, 421, 530, 550
        CDUP
         200
         500, 501, 502, 421, 530, 550
        SMNT
         202, 250
         500, 501, 502, 421, 530, 550

Fermeture de session

        REIN
         120
         220
         220
         421
         500, 502
        QUIT
         221
         500

Paramètres de transfert

        PORT
         200
         500, 501, 421, 530
        PASV
         227
         500, 501, 502, 421, 530
        MODE
         200
         500, 501, 504, 421, 530
        TYPE
         200
         500, 501, 504, 421, 530
        STRU
         200
         500, 501, 504, 421, 530

Commandes de service fichiers

        ALLO
         200
         202
         500, 501, 504, 421, 530
        REST
         500, 501, 502, 421, 530
         350
        STOR
         125, 150
         (110)
         226, 250
         425, 426, 451, 551, 552
         532, 450, 452, 553
         500, 501, 421, 530
        STOU
         125, 150
         (110)
         226, 250
         425, 426, 451, 551, 552
         532, 450, 452, 553
         500, 501, 421, 530
        RETR
         125, 150
         (110)
         226, 250
         425, 426, 451
         450, 550
         500, 501, 421, 530
        LIST
         125, 150
         226, 250
         425, 426, 451
         450
         500, 501, 502, 421, 530
        NLST
         125, 150
         226, 250
         425, 426, 451
         450
         500, 501, 502, 421, 530
        APPE
          125, 150
          (110)
          226, 250
          425, 426, 451, 551, 552
          532, 450, 550, 452, 553
          500, 501, 502, 421, 530
         RNFR
          450, 550
          500, 501, 502, 421, 530
          350
         RNTO
          250
          532, 553
          500, 501, 502, 503, 421, 530
         DELE
          250
          450, 550
          500, 501, 502, 421, 530
         RMD
          250
          500, 501, 502, 421, 530, 550
         MKD
          257
          500, 501, 502, 421, 530, 550
         PWD
          257
          500, 501, 502, 421, 550
         ABOR
          225, 226
          500, 501, 502, 421

Commandes d'information

         SYST
          215
          500, 501, 502, 421
         STAT
          211, 212, 213
          450
          500, 501, 502, 421, 530
         HELP
          211, 214
          500, 501, 502, 421

Commandes diverses

         SITE
          200
          202
          500, 501, 530
         NOOP
          200
          500, 421


Précédent - Suivant - Retour au sommaire