Chrome 87 Beta Brings Further FTP Deprecation, Cookie Store API

[mdedetrich]

You know that it requires SSH, right?

(and if you are talking about FTPS, nobody uses that)


Furthermore, the difficulty of getting a file from HTTP vs. FTP:

-FTP-
1. Connect
2. Login with anonymous username
3. Enter some binary mode
4. Send a few commands to further make the server happy
5. CD to directory
6. Send the get file command
7. Get the file

-HTTP-
1. Connect
2. GET /file HTTP/1.1
3. Get the file

As someone who works with HTTP daily, I think you are under-estimating the complexity of HTTP. If we are strictly dealing with file transfer, its more complex than FTP. Of course HTTP is typically abstracted away into libraries and clients (i.e. curl) but the actual protocol is not as simple as you are presenting.

There is a point that Chrome has a HTTP client since its is a browser but thats something else.

I know, as my file manager (Dolphin) supports it along with FISH, but I never heard of a browser supporting SFTP and how that would work, if it would need a SSL certificate.

Considering the amount of scope creep that browsers have had, I don't think this comparatively would be a problem.

[tildearrow]

As someone who works with HTTP daily, I think you are under-estimating the complexity of HTTP. If we are strictly dealing with file transfer, its more complex than FTP. Of course HTTP is typically abstracted away into libraries and clients (i.e. curl) but the actual protocol is not as simple as you are presenting.

Of course, I know web servers/clients typically deliver more headers than my example, but the detail to consider here is the time it takes to actually begin retrieving the file.

Let's say that the latency between the user is 150ms.
Both protocols use TCP, and have some form of command status check.

This means that every command takes at least 300ms to process (one send and one receive).

Therefore (adding 300ms for the initial SYN):

- FTP takes: 300 + 6*300 = 2100ms before file transfer begins
- HTTP takes: 300 + 1*300 = 600ms before file transfer begins

[mdedetrich]

Of course, I know web servers/clients typically deliver more headers than my example, but the detail to consider here is the time it takes to actually begin retrieving the file.

Let's say that the latency between the user is 150ms.
Both protocols use TCP, and have some form of command status check.

This means that every command takes at least 300ms to process (one send and one receive).

Therefore (adding 300ms for the initial SYN):

- FTP takes: 300 + 6*300 = 2100ms before file transfer begins
- HTTP takes: 300 + 1*300 = 600ms before file transfer begins

Again this also is misleading.

FTP is actually faster than HTTP when it comes to saturating your network connection for downloading of large files. So while FTP is slower for multiple small files (HTTP was designed to handle this case better since websites often initiate a lot of requests), its faster for the other case, i.e. large big files. FTP also allows persisting a connection (doing this in HTTP isn't that standard because it was originally designed around request/response).

Some basic googling would show you this https://stackoverflow.com/questions/...sferring-files .

Heck, an extension to FTP called GridFTP is used by the Hadron Collider as a basis for transferring massive sized files around efficiently. The FTP protocol was designed to be really good at transferring large files, they do also have different use cases.

[drownthepoor]

I know, as my file manager (Dolphin) supports it along with FISH, but I never heard of a browser supporting SFTP and how that would work, if it would need a SSL certificate.

It's supported as a protocol in the web address: ftp://www.ssomesite.net/ftp/images-ftp/