3

阅读 FTP RFC (RFC959),我注意到一些我从未见过的模式,并且确实似乎没有被流行的 FTP 软件(例如 vsftpd)实现。特别是对于STRU命令,常用的只有文件模式“STRU F”,而对于MODE命令,常用的只有流模式“MODE S”。

所以问题是,当遵循开发可互操作的 FTP 客户端和服务器软件的最佳实践时:

  • 支持其他 STRU 选项(记录和页面)是否有用?这些看起来像是非常老式的东西。
  • 支持其他 MODE 选项(块和压缩)有用吗?我可以看到压缩点,但我特别想知道是否有任何客户端/服务器会期望块在那里。
  • 是否有关于哪些现有 FTP 实施支持哪些选项的调查?

(在模式一上,我可以看到为什么压缩是有用的,我更想知道是否有任何客户端/服务器会期望块模式存在)。

4

3 回答 3

3

我维护一个自定义的 FTP 服务器,并经常参考http://cr.yp.to/ftp.html来解决这些问题。具体来说,我遵循了http://cr.yp.to/ftp/type.html上关于 TYPE/MODE/STRU 的建议,到目前为止没有任何问题。

除了“STRU F”之外,我见过的任何客户端都没有发送 STRU 请求。同样,我只见过“MODE S”。

于 2009-09-23T06:57:43.117 回答
0

我建议搜索开源 FTP 客户端和服务器(尤其是那些仍在积极更新的)并查看其中有多少实现了这些“过时”的传输模式。

我曾经(大约七年前)做了一个 FTP 客户端,并且只实现了最基本的传输模式(ASCII 和二进制,如果我没记错的话)。使用时从未遇到过任何服务器的问题。

于 2009-09-22T16:52:28.433 回答
0

听起来您最关心的是互操作性。客户端和服务器之间的答案有点不同。

对于服务器,您希望实现客户端使用的基本模式。对于每个客户端,您至少需要支持一种配置,因此组合的数量应该相对较少。超出最低限度,支持主动和被动模式可能是主要的补充(mozilla 社区长期以来一直希望被动支持,而且这可能永远不会发生)。

如果您是客户,提供良好的 URL 支持和日期/时间处理可能是最大的障碍。

于 2009-09-23T06:36:26.180 回答