哪些FTP传输模式被广泛使用？
阅读 FTP RFC (RFC959)，我注意到一些我从未见过的模式，而且确实似乎没有被流行的 FTP 软件（例如 vsftpd）实现。 具体地，对于STRU命令，通常仅使用文件模式“STRU F”，而对于MODE命令，通常仅使用流模式“MODE S”。
因此，问题是，在遵循开发可互操作 FTP 客户端和服务器软件的最佳实践时：
- 支持其他 STRU 选项（记录和页面）是否有用？ 这些看起来像是非常老式的东西。
- 支持其他模式选项（块和压缩）有用吗？ 我可以看到压缩的要点，但我特别想知道是否有任何客户端/服务器会期望块在那里。
- 是否有任何关于现有 FTP 实现支持哪些选项的调查？
（在模式一上，我可以明白为什么压缩是有用的，我更想知道是否有任何客户端/服务器会期望块模式存在）。
Reading the FTP RFC (RFC959), I notice some modes that I've never seen used, and indeed don't seem to be implemented by popular FTP software (vsftpd for example). In particular, for the STRU command, only file mode "STRU F" is commonly used, and for the MODE command, only stream mode "MODE S" is commonly used.
So the question is, when following best practice for developing interoperable FTP client and server software:
- Is it useful to support the other STRU options (record and page)? These seem like something very old fashioned.
- Is it useful to support the other MODE options (block and compressed)? I can see the point in compressed, but I'm particularly wondering whether any clients/servers will expect block to be there.
- Are there any surveys of which existing FTP implementations support which options?
(On the MODE one, I can see why compressed is useful, I'm more wondering about whether any clients/servers will expect block mode to be there).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我维护一个自定义 FTP 服务器并定期参考 http://cr.yp.to/ftp.html< /a> 对于这类问题。 具体来说，我遵循了 http://cr.yp.to 上对 TYPE/MODE/STRU 的建议/ftp/type.html 到目前为止还没有出现任何问题。
除了“STRU F”之外，我见过的连接中没有客户端发送过 STRU 请求。 同样，我只见过“MODE S”。
I maintain a custom FTP server and regularly refer to http://cr.yp.to/ftp.html for these sort of questions. Specificly, I followed the suggestions for TYPE/MODE/STRU at http://cr.yp.to/ftp/type.html and so far have had no issues.
No client I've seen connect has sent an STRU request besides "STRU F". Similarly, I've only ever seen "MODE S".
我建议搜索开源 FTP 客户端和服务器（尤其是那些仍在积极更新的客户端和服务器），并查看其中有多少实现了这些“过时的”传输模式。
我曾经（大约七年前）制作过一个 FTP 客户端，并且只实现了最基本的传输模式（ASCII 和二进制，如果我没记错的话）。 使用它时从未遇到任何服务器问题。
I would suggest to search for open source FTP clients and servers (especially those still being actively updated) and look at how many of them implement these "obsolete" transfer modes.
I made once (about seven years ago) a FTP client and implemented just the most basic transfer modes (ASCII and binary, if I remember correctly). Never had a problem with any server when using it.
听起来您最关心的是互操作性。 客户端和服务器之间的答案有点不同。
对于服务器，您想要实现客户端使用的基本模式。 对于每个客户端，您需要至少支持一种配置，因此组合数量应该相对较少。 除了最低限度之外，支持主动和被动模式可能是主要的补充（mozilla 社区长期以来一直希望被动支持，并且 这可能永远不会发生）。
如果您是客户，提供良好的 URL 支持和日期/时间处理可能是最大的障碍。
It sounds like you are mostly concerned with interoperability. The answer is a bit different between client and server.
For server, you want to implement the basic modes that clients use. For every client, you need to support a minimum of one configuration, so the number of combinations should be relatively low. Beyond the minimum, supporting active -and- passive mode would probably the major addition (the mozilla community has wanted passive support for a long time, and it is probably never going to happen).
If you are a client, providing good URL support and date/time handling is probably the biggest barrier.