RFC FTP : spécifications déclaratives
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 - Stream
STRU - File, 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.
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.
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 les uns des autres 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.
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>
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
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
|