Ein PySocks-Standardwert verdrahtet ftplib nicht um
Verfolgen Sie die Sockets, die ftplib tatsächlich erzeugt, statt anzunehmen, set_default_proxy ändere Pythons native Socket-Implementierung.
socks.set_default_proxy() speichert Standardwerte für künftige PySocks-socksocket-Objekte. Es ersetzt nicht Pythons native Socket-Klasse. Folglich leitet es ftplib nicht allein deshalb um, weil der Aufruf vor einer FTP-Verbindung erfolgt.
Folgen Sie den Konstruktoren, nicht der Variablen, die die Proxy-URL hält. ftplib erzeugt eine Steuerverbindung und weitere Übertragungsverbindungen. Bei passivem FTP beweist eine erfolgreiche Anmeldung nur, dass die Steuerverbindung funktionierte; der Datensocket für ein Verzeichnislisting oder eine Dateiübertragung braucht ebenfalls die vorgesehene Route.
Ein Rezept, das socket.socket ersetzt oder ein Modul umhüllt, führt eine andere Aktion aus als das Setzen von PySocks-Standardwerten. Es kann andere Bibliotheken beeinflussen, die dasselbe Modul nutzen. Das anschließende vorübergehende Wiederherstellen des Originals isoliert gleichzeitige Verbindungen nicht von der Änderung.
Eine eigene ftplib-Unterklasse kann die Verbindungswege abdecken, doch kopierte Interna tragen die Annahmen der Python-Version, aus der sie stammen, einschließlich Timeout-Sentinels und Protokollbehandlung. Aktualisierungen der Standardbibliothek aktualisieren die Kopie nicht.
Wählen Sie einen gepflegten Client oder eine unterstützte Integration für den geforderten Proxy und FTP-Modus. Ein PycURL-Beispiel für passiven FTP-Download zeigt einen separaten Clientpfad. Bei einer anwendungseigenen Anpassung ermitteln Sie, welcher Konstruktor jeden Steuer- und Datensocket öffnet, und bewahren Sie das Verhalten der Vorgängerschicht, das er ersetzt. Ein korrekter Proxy-Wert ist nur dann nützlich, wenn diese Konstruktoren ihn tatsächlich verwenden.