The Hypertext Transfer Protocol (HTTP) and File Transfer Protocol (FTP) can be used to perform file transfers to and from the local computer to a remote server. SocketTools includes components for both protocols, and their interface was designed to make them interchangeable with one another.
Internally these two protocols work very differently from one another and there are situations where using one has certain advantages over the other.
In some cases, you may not have a choice and must use whichever protocol is available to you. However, it’s quite common for a server to support both, so which would be the best option for your applications to use?
In this article we will be referring to HTTP and FTP, but in general we recommend always using a secure connection (TLS) whenever possible. In practical terms, when we recommend using HTTP, we’re really recommending you use HTTPS. Likewise, if we recommend using FTP, we’re recommending you use FTPS or SFTP.
The distinction between FTPS and SFTP is one that can be confusing to a lot of developers, so it’s worth mentioning here. FTP is a standard file transfer protocol which was first documented in RFC 959 and has had many extensions added over the years. One of those extensions to the protocol was support for SSL and then TLS encryption.
SFTP has a similar name, but it is very different from FTP. Rather than using TLS to encrypt data over a standard FTP connection, SFTP uses a protocol called Secure Shell (SSH) to perform the file transfers. SocketTools supports both protocols, and our FTP API provides the same coding interface to your applications, although they work in very different ways.
One additional factor with using FTPS (FTP + TLS) is you will need to know if the server requires an implicit or explicit TLS connection. This determines how the client (your application) negotiates with the server to begin encrypting the data being exchanged.
With an implicit TLS connection, the secure connection is established as soon as the client connects with the server. With explicit TLS, the client establishes a standard (non-secure) connection with the server and then sends a command to the server, asking it to switch to using TLS before any private information is exchanged.
By default, implicit TLS is used with FTP connections on port 990, and explicit TLS is used with connections on port 21. SocketTools provides options which allow you to use either type of connection.
It’s important to know if the server you’re connecting with requires an FTP connection using FTPS (typically on port 21 or 990), or if it provides an SSH service and requires you to use SFTP (typically on port 22). You won’t be able to connect to an FTPS server using SFTP and vice versa.
One advantage of a secure HTTP connection is that it doesn’t introduce any of this complexity. It always uses implicit TLS, with encryption negotiated immediately after the connection is made. By default, a secure HTTP connection will use port 443, while a standard connection will use port 80.
If your application needs to download data from a server to the local computer, we generally recommend that you use HTTP. The primary reason for this is because it provides simplicity and compatibility with firewalls and NAT (Network Address Translation) routers.
To transfer files, FTP requires two separate network connections to the server, one for the control channel where commands are sent, and a second connection for the data transfer. In addition, FTP has two different transfer modes, one called “active” where the server connects back to the client, and another called “passive” where the client establishes two outbound connections.
Passive mode transfers generally work better with NAT routers but may require changes to the firewall configuration to allow access to a large range of outbound ports for the secondary connection.
HTTP only uses a single outbound connection to the server with your request and the server’s response using the same connection. Because HTTP is such a ubiquitous protocol, virtually all firewalls are configured to allow it (otherwise you wouldn’t be able to browse websites). NAT routers don’t need to make any special considerations for how the connection is made and there’s no need to allow access to range of ports on the local system.
If you need to upload files to the server, this is where things can be a bit more complicated. As its name implies, FTP was designed for the purpose of transferring data files, while HTTP was primarily designed for document retrieval, whether that’s for the purposes of being viewed in a browser or stored locally.
Of course, today HTTP is used for much more than simply viewing documents. Web servers can be configured to allow file uploads using the PUT or POST commands, and there are also some newer extensions to the protocol such as the PATCH command. However, this requires the server administrator to explicitly enable the command.
A web server “out of the box” will typically not allow any client to use the PUT command to upload data and using the POST command would require a server-side script to accept the data and store it on the server. The server administrator will have to take steps to allow the server to accept uploads, and may require you to take additional authentication steps, such as using an OAuth 2.0 bearer token and/or an API key which grants you access to the file storage area.
FTP servers have upload functionality essentially built-in, and typically they only require the user to authenticate themselves with a username and password. Whether you have permissions to upload a file normally depends on the individual user permissions and the permissions granted to the user where the file is being stored.
FTP can also be preferred by server administrators because there’s no need for server-side scripts to handle the upload. This can mean fewer potential configuration and security issues. For example, a poorly written PHP script which handles the PUT or POST command for the web server could allow a client to store a file where it shouldn’t, using the access permissions of the web server itself rather than the individual user.
If your application needs to manage files on the server, FTP is the protocol we recommend you use. By file management, we mean anything beyond simply downloading or uploading files; this can include listing the files available on the server, renaming and moving files, changing their access permissions and deleting them.
Although HTTP servers can have these kinds of capabilities through extensions like WebDAV (Web Distributed Authoring and Versioning), they are not universally available. The FTP standard defines commands specifically for file management and they are supported by most servers, based on the access permissions of the user.
One of the most frequent questions we get from developers is how to get a list of files to download from a web server using HTTP, and the unfortunate answer is “it depends”. There is no universal standard supported by all web servers to return a list of file data for a specific folder where files are stored.
The most common approach is to simply request the index using the folder path. However, most web servers must be configured to allow this and there is no standardized format for what that output will look like. Different types of web servers can also return this information in different formats (such as the size and date of the file).
With FTP, file information can be obtained using a standardized format and there are commands explicitly provided to list information about individual files, lists of file names using wildcards (something web servers generally don’t support) and all files within specific folders.
If your application only needs to download files from a server, and you can use either HTTP or FTP, we recommend using HTTP for its simplicity and compatibility with most firewalls and other network security devices.
For most other file transfer functions, including uploading files, renaming or moving files and listing available files for the user on that server, we recommend using FTP (either FTPS or SFTP) whenever possible. FTP is a protocol built for that purpose and provides better standardized functionality that will work reliably with most servers.