4 ms·

You're saying it was normal (and is even today) to show HTML files over ftp links? I've never seen a browser do HTML over ftp, and while I am a youngster compar

You're saying it was normal (and is even today) to show HTML files over ftp links? I've never seen a browser do HTML over ftp, and while I am a youngster compared to HTTP (I stared to do web stuff in the early 2000's) the sites where I've seen that had both HTTP and FTP modes the ftp mode only downloaded the file, it did not show it. > More broadly, this is a tradeoff between the traditional vision of the WWW as a vast library, in which human knowledge accumulates over time and becomes accessible to all, and the strip-mall vision of the WWW as a means to sell people things they don't need. I don't get this at all. * Are you saying FTP is a fundamentally better protocol to download files than HTTP? * Are you saying that it would be easier to run a FTP server than a HTTP server? * Do you think that FTP-only-sites generally depend on HTML-over-FTP for browsing? Because that's something I've never seen AFAIK, either they use HTTP-only or HTML-over-HTTP for browsing and FTP for download. I get the "strip-mall vision of the WWW as a means to sell people things they don't need" complaint, but that does not seem related to the protocol discussion of HTTP and FTP at all.

classichasclass 5y ago
> You're saying it was normal (and is even today) to show HTML files over ftp links? I've never seen a browser do HTML over ftp Firefox supported this completely until Fx61, when it disabled FTP subresources on HTTPS. Even then, you could still view HTML pages served over FTP until Fx70.
- SahAssar 5y ago
  I might just be not lurking in the right corners of the internet, but is there a specific reason for serving HTML over FTP vs serving HTML over HTTP? Not allowing FTP subresources on HTTPS is basically the same as not allowing HTTP subresources on HTTPS, that is just logical.
  - JackGreyhat 5y ago
    Not having to run a webserver? Some resources might be located on systems which do not support or allow it.
    - SahAssar 5y ago
      Is running a webserver different from running a ftp server? I've run both and never noticed much of a difference.
      - JackGreyhat 5y ago
        Well, I'm not saying running ftp to serve html is better. All I'm saying is that it can sometimes be the only supported option, or viable option. And there are major differences. Webserver access permissions vs. ftp server permissions for example?
        SahAssar 5y ago
        > Webserver access permissions vs. ftp server permissions for example? What I'm saying is: is there a meaningful difference? Both need to bind to a port that is privileged and read files from the served directory. There is no difference between a ftpserver and a webserver from a permissions/privilege perspective.
        JackGreyhat 5y ago
        Well, that's right. There is no meaningful difference in the sense that they both have to serve files from a storage backend, over a port to a frontend. I was comparing ftp folder permissions with webserver htaccess permissions. What I really ment was access control.
        SahAssar 5y ago
        Gotcha, but htaccess is specific to one server (apache). You can leave that out for basic things for basic use cases (just set read/write as you would for a normal unix user) and for more granular things you need to configure FTP just like you need HTTP.
dvfjsdhgfv 5y ago
> You're saying it was normal (and is even today) to show HTML files over ftp links? I've never seen a browser do HTML over ftp, and while I am a youngster compared to HTTP (I stared to do web stuff in the early 2000's) the sites where I've seen that had both HTTP and FTP modes the ftp mode only downloaded the file, it did not show it. Of course they do, it's quite normal. Here's Netscape Navigator: https://i.imgur.com/I7dfetY.png https://i.imgur.com/I7dfetY.png
kragen 5y ago
> I get the "strip-mall vision of the WWW as a means to sell people things they don't need" complaint, but that does not seem related to the protocol discussion of HTTP and FTP at all. Web pages that are profit-making ventures, with employees dedicated to working around the latest browser featurectomies, will have no trouble with this sort of constant change. Web pages that are just HTML files that someone uploaded to a server in 02003 will disappear into the memory hole. They're already hard to find, but now they'll be totally inaccessible. FTP is a bad protocol. HTTP servers are generally easier to run than FTP servers, and especially to run in a secure fashion. None of that is relevant to whether we should break functionality that has been core to the WWW project for 31 years.
- SahAssar 5y ago
  I don't get how any of your comment is about HTTP vs FTP, even the security part seems to be about HTTPS, right? If we are talking about FTP and HTTP (not FTPS or SFTP and HTTPS) is there any meaningful difference?
  - kragen 5y ago
    > even the security part seems to be about HTTPS, right? No, I mean that a lot of FTP servers by default want you to do password authentication (yes, in cleartext); by default they grant access to your whole filesystem; and a minimal FTP server is significantly more complicated than a minimal HTTP server, and so it's more likely to contain vulnerabilities. Also, by default, most FTP servers support writing to files, and HTTP servers don't. I'm not talking about eavesdropping on the protocol itself or packet spoofing, which I agree are equally easy with FTP and unencrypted HTTP. This HTTP server I wrote is, I think, 324 instructions of machine code, and it doesn't use any libraries: http://canonical.org/~kragen/sw/dev3/server.s http://canonical.org/~kragen/sw/dev3/server.s. I think it's plausible that it contains no security vulnerabilities, other than a DoS by flooding it with connections. I have a fair bit of confidence that it doesn't have an exploitable RCE vulnerability. I'm not sure if there's ever been an FTP server we could say that about. But none of that is relevant to whether we should break functionality that has been core to the WWW project for 31 years.

classichasclass 5y ago

> You're saying it was normal (and is even today) to show HTML files over ftp links? I've never seen a browser do HTML over ftp Firefox supported this completely until Fx61, when it disabled FTP subresources on HTTPS. Even then, you could still view HTML pages served over FTP until Fx70.

SahAssar 5y ago
I might just be not lurking in the right corners of the internet, but is there a specific reason for serving HTML over FTP vs serving HTML over HTTP? Not allowing FTP subresources on HTTPS is basically the same as not allowing HTTP subresources on HTTPS, that is just logical.
- JackGreyhat 5y ago
  Not having to run a webserver? Some resources might be located on systems which do not support or allow it.
  - SahAssar 5y ago
    Is running a webserver different from running a ftp server? I've run both and never noticed much of a difference.
    - JackGreyhat 5y ago
      Well, I'm not saying running ftp to serve html is better. All I'm saying is that it can sometimes be the only supported option, or viable option. And there are major differences. Webserver access permissions vs. ftp server permissions for example?
      - SahAssar 5y ago
        > Webserver access permissions vs. ftp server permissions for example? What I'm saying is: is there a meaningful difference? Both need to bind to a port that is privileged and read files from the served directory. There is no difference between a ftpserver and a webserver from a permissions/privilege perspective.
        JackGreyhat 5y ago
        Well, that's right. There is no meaningful difference in the sense that they both have to serve files from a storage backend, over a port to a frontend. I was comparing ftp folder permissions with webserver htaccess permissions. What I really ment was access control.
        SahAssar 5y ago
        Gotcha, but htaccess is specific to one server (apache). You can leave that out for basic things for basic use cases (just set read/write as you would for a normal unix user) and for more granular things you need to configure FTP just like you need HTTP.

dvfjsdhgfv 5y ago

> You're saying it was normal (and is even today) to show HTML files over ftp links? I've never seen a browser do HTML over ftp, and while I am a youngster compared to HTTP (I stared to do web stuff in the early 2000's) the sites where I've seen that had both HTTP and FTP modes the ftp mode only downloaded the file, it did not show it. Of course they do, it's quite normal. Here's Netscape Navigator: https://i.imgur.com/I7dfetY.png https://i.imgur.com/I7dfetY.png

kragen 5y ago

> I get the "strip-mall vision of the WWW as a means to sell people things they don't need" complaint, but that does not seem related to the protocol discussion of HTTP and FTP at all. Web pages that are profit-making ventures, with employees dedicated to working around the latest browser featurectomies, will have no trouble with this sort of constant change. Web pages that are just HTML files that someone uploaded to a server in 02003 will disappear into the memory hole. They're already hard to find, but now they'll be totally inaccessible. FTP is a bad protocol. HTTP servers are generally easier to run than FTP servers, and especially to run in a secure fashion. None of that is relevant to whether we should break functionality that has been core to the WWW project for 31 years.

SahAssar 5y ago
I don't get how any of your comment is about HTTP vs FTP, even the security part seems to be about HTTPS, right? If we are talking about FTP and HTTP (not FTPS or SFTP and HTTPS) is there any meaningful difference?
- kragen 5y ago
  > even the security part seems to be about HTTPS, right? No, I mean that a lot of FTP servers by default want you to do password authentication (yes, in cleartext); by default they grant access to your whole filesystem; and a minimal FTP server is significantly more complicated than a minimal HTTP server, and so it's more likely to contain vulnerabilities. Also, by default, most FTP servers support writing to files, and HTTP servers don't. I'm not talking about eavesdropping on the protocol itself or packet spoofing, which I agree are equally easy with FTP and unencrypted HTTP. This HTTP server I wrote is, I think, 324 instructions of machine code, and it doesn't use any libraries: http://canonical.org/~kragen/sw/dev3/server.s http://canonical.org/~kragen/sw/dev3/server.s. I think it's plausible that it contains no security vulnerabilities, other than a DoS by flooding it with connections. I have a fair bit of confidence that it doesn't have an exploitable RCE vulnerability. I'm not sure if there's ever been an FTP server we could say that about. But none of that is relevant to whether we should break functionality that has been core to the WWW project for 31 years.