- Unless tunneled over a secure socket, FTP is 100% insecure.
This is true for HTTP.
- The spec defines no way of setting the modification dates/times of files.
The HTTP RFC defines the Last-Modified header.
- The spec defines no reliable way of determining the string encoding used for filenames.
The HTTP RFC defines several headers related to encoding.
- FTP was designed to be used interactively by a human sitting at a terminal, not by a GUI application working on the human's behalf. The spec doesn't even define the output format that should be used for directory listings.
This problem doesn't translate exactly to HTTP as it isn't used in the same manner. Directory listings are typically sent as HTML and a user clicks a link which all browsers are able to handle trivially. WebDAV adds features similar to FTP, but it is much more standardized.
- The spec defines no way of dealing with file metadata, such as Unix permissions, owners, and groups.
There are HTTP error codes which indicate lack of permission, but there are no RFC-defined headers for these things. I believe WebDAV does define a method to deal with them.
- FTP requires a minimum of two socket connections to transfer a file: the control connection, which is established first, and then data connections which are created and destroyed every time you transfer a single file, or request a directory listing.
HTTP has no such requirement. Keep-alive prevents sockets from being closed and the same connection can be used to get a directory listing and then transfer a file. There are no separate data and control connections.
- FTP is not friendly with firewalls. Because it constantly needs to establish new connections, this has led us to "passive mode" which might as well be black magic as far as most people are concerned.
This is FTP's biggest flaw and this problem absolutely does not exist with HTTP. Once it is encrypted FTP is impossible to handle in a reasonable manner with a firewall.
In active mode FTP creates one connection to a well-known port for the control channel (21). For the data connection the server attempts to establish a connection from a well-known port (20) to a high-numbered port on the client. This obviously doesn't work well with a firewall in front of the client.
Passive mode modifies this arrangement so that the data channel comes from the client to the server. The problem is the ports used. On both ends the port will be a high-numbered. This requires allowing connections from any high-numbered port (withing a large range) to any high-numbered port. Some firewalls understand the FTP protocol and are able to see the port that is to be used; the server gives the client this port with a command in the control connection. The firewall can then allow that specific connection. Once the control connection is encrypted this is impossible.
Now then. How do his arguments apply equally to HTTP?
"Almost all" might have been hyperbole, but "many" is certainly true.
On the other hand, HTTP is clearly far superior to FTP, especially if you include extensions like WebDAV and the power of custom headers.
I was just pointing out, insecure formats that don't define how to do listings or set mod times or deal with Unix permissions can be quite good. FTP sucks mostly because of the ports/multiple connection issue, as you pointed out.
This is true for HTTP.
- The spec defines no way of setting the modification dates/times of files.
The HTTP RFC defines the Last-Modified header.
- The spec defines no reliable way of determining the string encoding used for filenames.
The HTTP RFC defines several headers related to encoding.
- FTP was designed to be used interactively by a human sitting at a terminal, not by a GUI application working on the human's behalf. The spec doesn't even define the output format that should be used for directory listings.
This problem doesn't translate exactly to HTTP as it isn't used in the same manner. Directory listings are typically sent as HTML and a user clicks a link which all browsers are able to handle trivially. WebDAV adds features similar to FTP, but it is much more standardized.
- The spec defines no way of dealing with file metadata, such as Unix permissions, owners, and groups.
There are HTTP error codes which indicate lack of permission, but there are no RFC-defined headers for these things. I believe WebDAV does define a method to deal with them.
- FTP requires a minimum of two socket connections to transfer a file: the control connection, which is established first, and then data connections which are created and destroyed every time you transfer a single file, or request a directory listing.
HTTP has no such requirement. Keep-alive prevents sockets from being closed and the same connection can be used to get a directory listing and then transfer a file. There are no separate data and control connections.
- FTP is not friendly with firewalls. Because it constantly needs to establish new connections, this has led us to "passive mode" which might as well be black magic as far as most people are concerned.
This is FTP's biggest flaw and this problem absolutely does not exist with HTTP. Once it is encrypted FTP is impossible to handle in a reasonable manner with a firewall.
In active mode FTP creates one connection to a well-known port for the control channel (21). For the data connection the server attempts to establish a connection from a well-known port (20) to a high-numbered port on the client. This obviously doesn't work well with a firewall in front of the client.
Passive mode modifies this arrangement so that the data channel comes from the client to the server. The problem is the ports used. On both ends the port will be a high-numbered. This requires allowing connections from any high-numbered port (withing a large range) to any high-numbered port. Some firewalls understand the FTP protocol and are able to see the port that is to be used; the server gives the client this port with a command in the control connection. The firewall can then allow that specific connection. Once the control connection is encrypted this is impossible.
Now then. How do his arguments apply equally to HTTP?