Discuter:File Transfer Protocol
Un article de Wikipédia, l'encyclopédie libre.
 |
Cet article fait partie des mille articles les plus consultés de Wikipédia en français. On propose d'évaluer leur avancement pour les intégrer au projet Wikipédia 1.0. |
| B | Cet article est classé comme d'Avancement B selon le Projet:Wikipédia 1.0 |
| Moyenne | Cet article est classé comme d'Importance moyenne selon le Projet:Wikipédia 1.0 |
 |
File Transfer Protocol fait partie du projet Informatique, qui a pour but d'enrichir le contenu de Wikipédia sur les sujets liés à l'informatique. Si vous voulez participer, vous pouvez modifier cet article ou visiter la page du projet où vous pourrez vous joindre au projet et consulter la liste des tâches et des objectifs. Le portail informatique pourrait aussi vous intéresser. |
| Bon début | Cet article a été classé comme d'Avancement BD selon le Tableau d'évaluation du projet. (Voir les statistiques) |
| Moyenne | Cet article a été classé comme d'Importance moyenne selon le Tableau d'évaluation du projet. (Contester?) |
Oops, oublié le commentaire: 16:46 jan 22, 2003 . . Ryo => correction de quelques accents manquants & ajout de FileZilla
Sommaire |
[modifier] PUT et GET ?
Bonjour à tous,
Dans la RFC, il n'est pas fait mention des commandes 'PUT', 'GET' (et certaines autres non plus). Les commandes officielles sont STOR (pour PUT) et RETR (pour GET). Il serait peut-être intéressant de le signaler dans le document qui dans sa forme actuelle laisse croire que les commandes principales sont celles respectant la RFC-959, alors que 'PUT' et 'GET' ressemblent plutôt à des alias pratiques sur les commandes STOR et RETR.
Qu'en pensez-vous ?
[modifier] Compréhension
Dans Vue d'ensemble :
Pour accéder à un serveur FTP, on le mode actif, tandis que les données sont échangées
Pour un lecteur béotien (ou pour n'importe quel lecteur), merci d'ajouter un verbe après le 'on' pour une meilleure compréhension. Merci.jpm2112 16 octobre 2005 à 18:07 (CEST)
[modifier] Erreur ?
Dans la description des différentes couches du réseau, le ftp est mis en 7. Alors que d'après mes souvenirs, le modèle TCP/IP est un modèle simplifié du modèle OSI et il n'y a qu'une couche application derriere la couche TCP. C'est d'ailleurs ce qui est montré dans la version anglaise. Mais je n'ai pas spécialement envie d'écrire des conneries, donc est ce qu'il y en a d'autre qui peuvent confirmer ?
wget est un client ftp ? c'est pas http ? Alainbb
[modifier] En théorie, oui... mais en pratique...
En théorie, le protocol FTP est formellement défini. Mais en pratique, je n'ai jamais vu un seul serveur FTP respecter le protocol FTP. Je peux en parler pour avoir programmé un client FTP. C'est d'ailleurs à un tel degré que c'en est un cas unique à ma connaissance : une norme dont on parle comme si on ignorait complétement qu'elle n'est absolument pas appliquée, alors que du coté applicatif on ne peut pas ignorer qu'elle n'est pas appliquée (sans jeux de mot). Heureusement qu'on ne se moque pas de toutes les normes de la même manière qu'on s'est moqué de celle-ci. Là où je veux en venir maintenant, c'est qu'il serait peut-être interessant de parler aussi du protocol réel, celui qui est utilisé en pratique, qui n'a rien à voir avec le protocol officiel, qui s'est imposé par les faits, qui est devenu une norme de fait, et qui n'est pourtant formalisé par aucune RFC. De toute façon il me semble illusoire qu'un retour à l'ordre ai lieu un jour, parce qu'il produirait trop de désordre pour être sérieusement envisageable : raison de plus pour affronter la réalité et parler de cette norme de faits.
Qu'en pensez-vous ?
--Hibou57 29 décembre 2006 à 14:39 (CET)
On en pense que le protocole est un sommet de crétinerie, notamment au niveau de la sécurité. C'est un des rares protocoles qui est non-sûr sur une couche réseau sure. Un protocole où soit le client soit le serveur est vulnérable à un vol du fichier ou une corruption du fichier, selon le sens du transfert.
L'idée de standardiser un port ftp-data, par exemple, est une invention totalement inepte, motivée juste par le fait que les 'admin' veulent pouvoir bricoler un pare-feu idiot (pléonasme).
Quand au transfert direct entre serveurs, avec un flux de données brut sans format spécifique, c'est quand même une invitation à l'usurpation d'identité assez hallucinante. (Mais à quoi ils pensaient ?)
En plus quel intérêt franchement de séparer control et data ? Si c'est juste pour démontrer que le NAT est une aberration contraire à l'esprit d'IP, merci, c'est assez évident en soit.
Bref je ne comprends pas que ce protocole préhistorique soit encore utilisé. Mais s'il l'est ce n'est certainement pour tous ses gadgets débiles.
--Wcorrector (d) 25 novembre 2007 à 00:25 (CET)
Pffffou ! Que de bile déversée par Wcorrector en seulement quelques lignes !
Les prémices du protocole FTP datent ne l'oublions pas de 1971 tel que décrits dans le RFC 114, une époque où le réseau ARPNET comptait sans doute guère plus de 100 serveurs. Petit flash-back :
- à l'époque personne ne pensait un jour se faire voler/corrompre un fichier ;
- les firewalls n'existaient pas d'ailleurs leur concept pas encore non plus ;
- l'usurpation d'identité encore moins ;
- la séparation entre contrôle et données est naturellement venue d'un besoin humain d'interrompre un transfert qui semble prendre plus de temps que prévu ;
- et tout cela fonctionnait bien avant que le NAT ne soit inventé seulement pour tenter de faire survire IPv4 alors que ce protocole est depuis devenu "préhistorique" (sic).
FTP survit encore sans doute parce que des centaines (n’est-ce pas plutôt des milliers ?) de librairies/modules implémentant ce protocole pour un usage ou un autre existent encore et fonctionnent toujours parfaitement. Quoi qu’en ait écrit Hibou57 l’an dernier il n’est pas toujours nécessaire d’implémenter l’ensemble des spécifications d’un protocole pour pouvoir s’en servir.
Sans être un fervent de FTP (c'est moyennement capricieux à mettre en oeuvre), je reconnais que je connais peu de protocoles informatiques ayant survécu aussi longtemps (plus de 35 ans) avec si peu d'altérations : le besoin de transférer des fichiers n’a finalement jamais remis en cause ce fondement.
