3 ms·

> Although one could standardise a mechanism for transferring record-oriented files over HTTP Or you could just provide a simple API over HTTP, whether an actu

> Although one could standardise a mechanism for transferring record-oriented files over HTTP Or you could just provide a simple API over HTTP, whether an actual REST system or a single endpoint one or two params with well defined inputs that can be accepted (a CGI, basically). Why bother formalizing some standard when the tools to handle this are so ubiquitous (Apache+$LANG on the server, cURL or wget on the client)? > SFTP doesn't include any support for record-oriented files, only the stream-oriented files used on Unix and Windows. That's because SFTP isn't really FTP (in the protocol sense) at all. It's just a specialized shell started after an SSH session/tunnel is created. That it includes FTP in the name is really just marketing because they wanted to supersede the real FTP. In that respect, it makes sense for them to just cover what 99% of the users of FTP needed and stop.

skissane 8y ago
curl and wget on the client can't easily do this, when the client is another mainframe/minicomputer OS with a record-oriented filesystem. I don't believe they have any platform-specific code to support record-oriented files. You probably can get it to work with external configuration (e.g. on z/OS, using JCL to invoke curl/wget with a DD statement which sets the necessary dataset parameters.) But FTP-over-TLS is already a well-documented and well-understood technology in mainframe environments. What possible advantage could one get by replacing it with something hacked together with Apache/curl/wget?
- kbenson 8y ago
  > I don't believe they have any platform-specific code to support record-oriented files. Yes, I was assuming a more traditional client, which is probably a mistake on my part. > What possible advantage could one get by replacing it with something hacked together with Apache/curl/wget? Well, there's always the obvious one, which is firewalls are much easier to deal with, since there aren't two separate ports in use, so you get rid of a whole class of network and firewall errors that are quite common.
  - skissane 8y ago
    > Well, there's always the obvious one, which is firewalls are much easier to deal with, since there aren't two separate ports in use, so you get rid of a whole class of network and firewall errors that are quite common. If possible, one should use extended passive mode (EPSV) over TLS. Then, we are just talking about two ports instead of one, without any of the connection tracking complexity on middle-boxes that active mode or non-extended passive mode can require (such as rewriting the IP address in the PASV command response to implement NAT). And then, you have to wonder, if you have to substantially change the software in use at the client and server (and possibly even write custom code, per your Apache+$LANG suggestion), are those significant changes really worth it just to save on one extra port open on the firewall?
    - kbenson 8y ago
      > And then, you have to wonder, if you have to substantially change the software in use at the client and server (and possibly even write custom code, per your Apache+$LANG suggestion), are those significant changes really worth it just to save on one extra port open on the firewall? Oh, sorry, I didn't make it clear before. I'm fully admitting that in the case of record-oriented file requirements, especially on the client side, FTPS probably doesn't have a better solution available. I was just noting that a vastly simplified firewall configuration that both doesn't require multiple ports opened (or to somehow read the PORT/PASV or EPRT/EPSV commands and open ports dynamically) is simpler, which is an advantage. It doesn't necessarily make up to the record-oriented storage problems that would have to be dealt with in those cases though.

skissane 8y ago

curl and wget on the client can't easily do this, when the client is another mainframe/minicomputer OS with a record-oriented filesystem. I don't believe they have any platform-specific code to support record-oriented files. You probably can get it to work with external configuration (e.g. on z/OS, using JCL to invoke curl/wget with a DD statement which sets the necessary dataset parameters.) But FTP-over-TLS is already a well-documented and well-understood technology in mainframe environments. What possible advantage could one get by replacing it with something hacked together with Apache/curl/wget?

kbenson 8y ago
> I don't believe they have any platform-specific code to support record-oriented files. Yes, I was assuming a more traditional client, which is probably a mistake on my part. > What possible advantage could one get by replacing it with something hacked together with Apache/curl/wget? Well, there's always the obvious one, which is firewalls are much easier to deal with, since there aren't two separate ports in use, so you get rid of a whole class of network and firewall errors that are quite common.
- skissane 8y ago
  > Well, there's always the obvious one, which is firewalls are much easier to deal with, since there aren't two separate ports in use, so you get rid of a whole class of network and firewall errors that are quite common. If possible, one should use extended passive mode (EPSV) over TLS. Then, we are just talking about two ports instead of one, without any of the connection tracking complexity on middle-boxes that active mode or non-extended passive mode can require (such as rewriting the IP address in the PASV command response to implement NAT). And then, you have to wonder, if you have to substantially change the software in use at the client and server (and possibly even write custom code, per your Apache+$LANG suggestion), are those significant changes really worth it just to save on one extra port open on the firewall?
  - kbenson 8y ago
    > And then, you have to wonder, if you have to substantially change the software in use at the client and server (and possibly even write custom code, per your Apache+$LANG suggestion), are those significant changes really worth it just to save on one extra port open on the firewall? Oh, sorry, I didn't make it clear before. I'm fully admitting that in the case of record-oriented file requirements, especially on the client side, FTPS probably doesn't have a better solution available. I was just noting that a vastly simplified firewall configuration that both doesn't require multiple ports opened (or to somehow read the PORT/PASV or EPRT/EPSV commands and open ports dynamically) is simpler, which is an advantage. It doesn't necessarily make up to the record-oriented storage problems that would have to be dealt with in those cases though.