I wanted to take some time to review FTP interaction; specifically the way Serv-U communicates with web browsers.
When you open up your Serv-U server to port 21 you give your users the option of coming to login from the many FTP client options.
In that list you will find your internet browsers (IE, Chrome, Mozilla) each browser has its own behavior and interaction with Serv-U.
When you go to a browser and type "ftp://10.110.X.XXX" and hit enter you will be starting the two way communication with the FTP server and the built in FTP client of the whatever browser you choose.
A typical Serv-U FTP communication will look something like this in the Serv-U / FTP client log (if the FTP client has a log)
- Connecting to XX.XXX.XX
- 220 - The 220 reply code is sent in response to a new user connecting to the FTP server to indicate that the server is ready for the new client
- USER XXXXXX (User login information)
- 331 User name okay, please send complete E-mail address as password.
- PASS ************ (User password information)
- User "UserName" logged in
- 230 - The server sends a 230 reply code in response to a command that has provided sufficient credentials to the server to grant the user access to the FTP server.
After this comes a combination of varying commands to retrieve information, apply configuration, and direct the user to correct directory.
After the FTP client sends the list of commands it will send a LIST command to the Serv-U server
Once Serv-U receives that LIST command it will send a the directory listing for that user.
Now for the interesting part. Serv-U is only listening for commands and replying to hose commands it does not dictate how or in what order a FTP client send the commands or when it logs off and on.
As you will see in the following test EVERY FTP client interacts very differently with Serv-U.
There is nothing Serv-U can do to force the clients to behave the same or connect when something outside of its control is stopping that connection such as firewall, configuration, antivirus, ISP, or many other factors.
In this example I opened a internet browser and follows the exact same steps each time
- Open the browser in privacy mode (to make sure information was not cached)
Chrome = Incognito
Mozilla = Private window
IE = CTRL+SHIFT+P = InPrivte Mode
- Navigate to ftp://10.XXX.X.XXX
- Enter user name and password
- Open "Testing" Folder
- Open "Black 135i.jpg" in browser
- Navigate back
- Right click on Black 135i file and save as.jpg
- Close browser page
As you will see each browser handled the interaction VERY differently
Starting with Mozilla version 32.0
It connects much like a typical FTP client (FileZilla, FTP Voyager) asking for credentials and
after a completed connection sending the LIST command to retrieve the directory listing and leaving the connection the Serv-U server OPEN
You will see in the attached (Mozilla FTP - 32.0.txt) file that once I start to navigate and preform the above steps Mozilla keeps the same connection and NEVER closes the connection.
When new information is requested Serv-U sends it and Mozilla displays or downloads that information.
Only once the Mozilla window is closed is the connection closed.
Here is a screenshot of that directory listing from Mozilla
Now to Chrome 37.0.2062.120
We see very different behavior as you are more than welcome to see in the attached log file (Chrome FTP - 37.0.2062.120.txt)
Unlike Mozilla Chrome does NOT keep the one original connection live the entire time.
Once Chrome logs in and completes the LIST command it immediately starts to download any additional files on that page and in its sub directories.
During testing I was unable to determine when it stops to do this and what its file size limits where and how it dictacts what is to large or small for this first mass download.
Because of this the log reads very differently than most FTP clients and constantly logs in and out of Serv-U.
One thing is for sure unlike FTP clients and Mozilla Chrome does indeed keep your username and password for its own use during the session.
Serv-U has NO CONTROL of how Chrome interacts with it and if you do not like the FTP logic it uses we can only suggest using a different browser or FTP client.
We also CANNOT stop a user from using Chrome or any browser / client.
Here is a screenshot of that directory listing from Chrome
Next is Microsoft Internet Explorer version 10
For the sake of this example I simply attempted the exact same steps as the above connections.
After the initial connection which did reach Serv-U and prompt me for user credentials I was greeted with a "This page can't be displayed" message from IE
A review of the Serv-U logs showed me what was wrong (Attached as IE FTP - 10.0.9200.1708.txt)
Internet Explorer did not send the full CWD (Change Working Directory) command like the other browsers
Without the Serv-U log showing me that the browser is not sending the correct information I would not know why this failed and if IE was the only resource for me as a user I would be stuck and would most likely have to contact the Serv-U administrator.
As a Serv-U admin there is nothing Serv-U can do to force IE to send the correct CWD command like both Chrome and Mozilla did.
Here is a screenshot from the failed IE connection
Additionally here is a discussion on TechNet concerning IE and its several issues with FTP connections
BONUS ROUND !
For our Windows users with issues with IE we have another method of native FTP connections
Simply open Windows Explorer (Windows Key + E)
and type the FTP address in the file path
Just like the browsers this will connect via port 21 to Serv-U and begin a line of communcation
Much like a standard FTP client and Mozilla this interacts with Serv-U in a typical manner with one connection requesting information as the user navigates the file directory.
Attached is the log named (Windows Explorer FTP - Windows 8 Enterprise.txt)
And a screenshot of a Explorer FTP connection
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process. Learn more today by joining now.