«FTP-proxy» kan tyde ein gateway som sjølv talar FTP. Å kople til han er annleis enn å be ein HTTP-proxy om CONNECT eller be ein SOCKS-tenar opne ein TCP-destinasjon.

Gatewayen treng målverten og kontoen, og kan først trengje si eiga innlogging. Produkt uttrykkjer den samtalen på ulike måtar:

OrdningVanleg kommandofasong
Målet koda i eit brukarnamnUSER target-user@target-host
Eiga gateway-innloggingGateway USER/PASS, deretter målinnlogginga
Eksplisitt destinasjonskommandoSITE target-host eller OPEN target-host, deretter den påkravde innlogginga

Dette er familiar av konvensjonar, ikkje éin standardsekvens for kvar gateway. Vel metoden som er dokumentert av administratoren og støtta av klienten.

Hald begge kontoane synlege i oppsettet

Målet sitt FTP-passord og gatewayen sitt passord kan vere ulike. Nokre gatewayar slår dei saman i éin USER/PASS-representasjon; andre krev separate utvekslingar. Å setje alle verdiar i éin streng kan ikkje gjenskape ein klient som må sende fleire kommandoar.

Dette forklarer ei nyttig grense i eldre FtpWebRequest-kode. Ei vanleg FTP-tilkopling til gatewayen, med eit gatewayspesifikt brukarnamn, kan passe nokre USER/PASS-ordningar. Ein gateway som krev ein eigen SITE- eller OPEN-samtale, treng ein klient som faktisk støttar den flyten. Proxy-eigenskapen i WebRequest er igjen eit anna grensesnitt.

WinSCP til dømes tilbyr eigne FTP-proxy-innloggingsmetodar i staden for å handsame alle gatewayar som eitt vertsfelt. Dei numeriske råinnstillingane høyrer til det dokumenterte API-et; bruk metodenamnet og den tiltenkte samtalen når du går gjennom ein konfigurasjon.

Etter innlogging treng filoverføringa framleis FTP-dataforbindinga og den valde TLS-modusen. Vellukka innlogging på kontrollkanalen er starten på den ruta, ikkje prov for at kvar dataoverføring allereie er tillaten.

Relaterte artiklar