• ono@lemmy.ca
    link
    fedilink
    English
    arrow-up
    20
    arrow-down
    1
    ·
    edit-2
    1 year ago

    The same “API” would be just as good over olde-schoole FTP instead of HTTPS.

    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.

    • fubo@lemmy.world
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      1 year ago

      Sure, sure, but is finger 8-bit-safe?

      'Cause if you have to uuencode it, that’s a whole mess.

      • ono@lemmy.ca
        link
        fedilink
        English
        arrow-up
        5
        arrow-down
        1
        ·
        edit-2
        1 year ago

        Sure, sure, but is finger 8-bit-safe?

        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.)