31–40 of 350 posts
I'm personally fine with this. FTP is a different protocol, just like BitTorrent. It's not part of the modern web, so it's just another loose end to tie up. Even though it will be around for a while, it's not relevant to Chrome's user audience/usecase.
And it's not a great protocol.
I know for a fact that HP distributes software and drivers over FTP files that they link to on their website. FTP isn't used much anymore, but IMO/IME, it's still nice to have for those rare times when you come across a file that you need to download and it's served over FTP.
Isn't it clear to everyone now that HTTP is the new IP and TCP? That all future protocols will subsist on a web tech substrate? Is that such a bad thing? The vocabulary of URLs and cookies is much richer and less centralized than the vocabulary of port numbers and connection tuples. Why should we keep FTP or other legacy non-HTTP protocols around? What are we buying? Slightly lower connection setup byte counts?
Earlier quoted context omitted.
We need a protocol for file transfers because having a protocol makes it more standardized and interoperable than if everyone rolls their own solution. Do we need browser support for it? It still happens now and then that a link will have an ftp target. That could be handled in the browser or it could open a separate url-handling application, as e.g. email or magnet urls do.
Yes, but as someone who's been around when FTP was a big thing, and HTTP only just came into fruition... what, really, is the benefit of FTP? In fact, FTP is actually a horrible protocol, that caused me much pain even back then: It uses separate "command" and "data" channels. The data channel is usually in the other direction, i.e. the client listens to a connection from the server when downloading a file. Passive mo…
This is not a bad thing in itself. It could enable you to download each file from a different, potentially better endpoint, while talking to the same server for coordination. It's just not the way we do it these days anymore - 3xx and anycast/CDNs solve that one to some extent. And NATs destroyed that idea being usable years ago. It's still fine in protocols like sip.
I know for a fact that HP distributes software and drivers over FTP files that they link to on their website. FTP isn't used much anymore, but IMO/IME, it's still nice to have for those rare times when you come across a file that you need to download and it's served over FTP.
Agreed completely, but Google don't care about "nice to have"; if it doesn't ultimately make them money, they couldn't care in the slightest, yet people here will often applaud this attitude as if it were progress.
Isn't it clear to everyone now that HTTP is the new IP and TCP? That all future protocols will subsist on a web tech substrate? Is that such a bad thing? The vocabulary of URLs and cookies is much richer and less centralized than the vocabulary of port numbers and connection tuples. Why should we keep FTP or other legacy non-HTTP protocols around? What are we buying? Slightly lower connection setup byte counts?
I know for a fact that HP distributes software and drivers over FTP files that they link to on their website. FTP isn't used much anymore, but IMO/IME, it's still nice to have for those rare times when you come across a file that you need to download and it's served over FTP.
Earlier quoted context omitted.
Yes, but as someone who's been around when FTP was a big thing, and HTTP only just came into fruition... what, really, is the benefit of FTP? In fact, FTP is actually a horrible protocol, that caused me much pain even back then: It uses separate "command" and "data" channels. The data channel is usually in the other direction, i.e. the client listens to a connection from the server when downloading a file. Passive mo…
> It uses separate "command" and "data" channels This is not a bad thing in itself. It could enable you to download each file from a different, potentially better endpoint, while talking to the same server for coordination. It's just not the way we do it these days anymore - 3xx and anycast/CDNs solve that one to some extent. And NATs destroyed that idea being usable years ago. It's still fine in protocols like sip.
Earlier quoted context omitted.
No one really uses FTP to transmit anything secret or confidential. Most of the time the password to that FTP server is just "guest" and the same file can also be retrieved by HTTP without authentication.
I work at a bank (opinions my own) and nearly everything we do (including modernization, but especially partnership communications) is FTP-based. It's just about the only real standard available when the code is older than most of the devs. We do use modern encryption and mutual TLS to authenticate and encrypt everything, including before password transmission when that's even an option, but FTP is still the backbone…
This is tangential to whether support for FTP is still worth keeping in a web browser, mind.
Earlier quoted context omitted.
The same could be said for HTTP... FTPS and SFTP do exist. That said, I agree that its outmoded today.
You'd think it's outmoded, but when the systems you're integrating with provide and expect multi-gigabyte files, the ability to append to a single file in a straightforward way and get some posix-ish APIs becomes a real life saver.