Sudsy said:
Two reasons:
- performance
- firewalls
vis:
- FTP is typically more efficient, i.e. there's less protocol overhead
compared to HTTP.
- Corporate firewalls often restrict the use of the ports needed to
use FTP. Port 80 (HTTP) is usually wide open.
So it depends on your target market. But Chris is quite correct in that
this is not really a Java question, merely one which affects those of
us attempting to make our Java services available to the largest user
population.
I believe that HTTP is much more efficient for anonymous downloads than
FTP is, due the the limited number of connections and conversations
required. For FTP, there is a whole process that has to be followed
before the first byte of real data is transferred:
connect to server on port 21, receive banner and login prompt
supply username
receive password prompt
supply password
receive OK message
change directory
receive OK message
set binary mode
receive Ok message
request PASV mode (optional, but likely)
receive OK message
request filename
receive data port on server to connect to
open TCP connection to new port
start downloading data file
v.s.
connect to server on port 80, request file and supply some headers
Server sends a few headers back, and immediately follows with the data
HTTP is also better supported by secure proxies than FTP is, as well as
supporting proxy authentication, which is usually a kludge in FTP.
HTTP also supports automatic compression of content (mod_gzip, for
instance), but if that is a concern, you would probably be supplying
pre-compressed data to start with.
HTTP/1.1 also support reconnects and partial transfer (resume). You may
argue that this is not that common, but that is implementation, and not
protocol.
The only thing that FTP is natively better at than HTTP, in my opinion,
is *authenticated* file uploads, and even this can be overcome by an
application, or implementing the PUT method. A web application for doing
large authenticated file uploads will most likely be 75% as efficient as
an FTP upload, due to the MIME encoding of the POST body. This is not an
issue when using the PUT method.
However, most browsers do not support PUT, I think. You could probably
write a custom script to do this (as you could with POST, in fact), but
this post is long enough already!
