Une valeur par défaut de PySocks ne réachemine pas ftplib

socks.set_default_proxy() stocke des valeurs par défaut pour les futurs objets PySocks socksocket. Il ne remplace pas la classe socket native de Python. Par conséquent, il ne réachemine pas ftplib simplement parce que l'appel a lieu avant une connexion FTP.

Suivez les constructeurs, pas la variable qui contient l'URL du proxy. ftplib crée une connexion de contrôle et des connexions de transfert supplémentaires. En FTP passif, une connexion réussie ne prouve que le bon fonctionnement de la connexion de contrôle ; le socket de données utilisé pour un listage ou un transfert de fichier a lui aussi besoin de la route prévue.

Une recette qui remplace socket.socket ou enveloppe un module effectue une autre action que la définition des valeurs par défaut de PySocks. Elle peut affecter d'autres bibliothèques qui partagent ce module. La restauration temporaire de l'original ensuite n'isole pas les connexions simultanées de la modification.

Une sous-classe personnalisée de ftplib peut couvrir les chemins de connexion, mais les rouages copiés portent les hypothèses de la version de Python dont ils proviennent, y compris les sentinelles de délai d'attente et le traitement du protocole. Les mises à jour de la bibliothèque standard ne mettent pas la copie à jour.

Choisissez un client maintenu ou une intégration prise en charge pour le proxy et le mode FTP requis. Un exemple de téléchargement FTP passif avec PycURL illustre un chemin client distinct. Pour une personnalisation propre à l'application, identifiez quel constructeur ouvre chaque socket de contrôle et de données et préservez le comportement d'origine qu'elle remplace. Une valeur de proxy correcte n'est utile que lorsque ces constructeurs la consomment réellement.