this post was submitted on 16 Sep 2023
67 points (97.2% liked)
Programming
18394 readers
139 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I can't agree with this, because FTP uses separate connections for requests and data, making it significantly more complicated than a single-connection protocol. (Note especially that the conventional default is for the remote host to initiate the second channel, so the requestor must also listen for and accept incoming connections!) If you want to stay old-school, the Finger protocol would be a better example of the point you're trying to make.
Practically speaking, though, HTTPS was an excellent choice here. It provides an appropriate level of data authenticity without needlessly complicating things, and easy-to-use implementations are ubiquitous.
Sure, sure, but is finger 8-bit-safe?
'Cause if you have to uuencode it, that's a whole mess.
Originally, I believe it was. (Edit: Confirmed by RFC 742.)
FTP, on the other hand, used 7-bit ASCII mode by default; Using 8-bit mode would normally require multiple request-response round trips. (There were eventually servers that defaulted to 8-bit, but they were atypical and arrived later.)