Internet Engineering Task Force (IETF) P. Hethmon
Request for Comments: 7151 Hethmon Brothers
Updates: 959 R. McMurray
Category: Standards Track Microsoft Corporation
ISSN: 2070-1721 March 2014
Internet Engineering Task Force (IETF) P. Hethmon
Request for Comments: 7151 Hethmon Brothers
Updates: 959 R. McMurray
Category: Standards Track Microsoft Corporation
ISSN: 2070-1721 March 2014
File Transfer Protocol HOST Command for Virtual Hosts
虚拟主机的文件传输协议主机命令
Abstract
摘要
The File Transfer Protocol, as defined in RFC 959, does not provide a way for FTP clients and servers to differentiate between multiple DNS names that are registered for a single IP address. This document defines a new FTP command that provides a mechanism for FTP clients and servers to identify individual virtual hosts on an FTP server.
RFC 959中定义的文件传输协议不提供FTP客户端和服务器区分为单个IP地址注册的多个DNS名称的方法。本文档定义了一个新的FTP命令，该命令为FTP客户机和服务器提供了一种识别FTP服务器上各个虚拟主机的机制。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7151.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7151.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
2. Document Conventions ............................................3
2.1. Basic Tokens ...............................................3
2.2. Server Replies .............................................4
3. The HOST Command ................................................4
3.1. Syntax of the HOST Command .................................5
3.2. HOST Command Semantics .....................................7
3.2.1. REIN Command Semantics ..............................8
3.2.2. User-PI Usage of HOST ...............................9
3.2.3. State Diagrams .....................................11
3.3. HOST Command Errors .......................................16
3.4. FEAT Response for HOST Command ............................17
4. Security Considerations ........................................17
5. IANA Considerations ............................................19
6. References .....................................................19
6.1. Normative References ......................................19
6.2. Informative References ....................................20
Appendix A. Unworkable Alternatives ...............................21
A.1. Overloading the CWD Command ................................21
A.2. Overloading the ACCT Command ...............................21
A.3. Overloading the USER Command ...............................22
A.4. Conclusion .................................................23
Appendix B. Acknowledgements ......................................23
1. Introduction ....................................................2
2. Document Conventions ............................................3
2.1. Basic Tokens ...............................................3
2.2. Server Replies .............................................4
3. The HOST Command ................................................4
3.1. Syntax of the HOST Command .................................5
3.2. HOST Command Semantics .....................................7
3.2.1. REIN Command Semantics ..............................8
3.2.2. User-PI Usage of HOST ...............................9
3.2.3. State Diagrams .....................................11
3.3. HOST Command Errors .......................................16
3.4. FEAT Response for HOST Command ............................17
4. Security Considerations ........................................17
5. IANA Considerations ............................................19
6. References .....................................................19
6.1. Normative References ......................................19
6.2. Informative References ....................................20
Appendix A. Unworkable Alternatives ...............................21
A.1. Overloading the CWD Command ................................21
A.2. Overloading the ACCT Command ...............................21
A.3. Overloading the USER Command ...............................22
A.4. Conclusion .................................................23
Appendix B. Acknowledgements ......................................23
It is common on the Internet for many DNS names to resolve to a single IP address. This practice has introduced the concept of a "virtual host", where a host appears to exist as an independent entity but, in reality, shares its physical resources with one or more similar hosts.
在Internet上，许多DNS名称解析为单个IP地址是很常见的。这种做法引入了“虚拟主机”的概念，其中主机看似作为独立实体存在，但实际上与一个或多个类似主机共享其物理资源。
Such an arrangement presents some problems for FTP servers, because an FTP server distinguishes incoming FTP connections by IP addresses rather than DNS names. Therefore, all DNS names that share a common IP address are handled by the same FTP server and share the same Network Virtual File System (NVFS).
这种安排给FTP服务器带来了一些问题，因为FTP服务器通过IP地址而不是DNS名称来区分传入的FTP连接。因此，共享公共IP地址的所有DNS名称都由相同的FTP服务器处理，并共享相同的网络虚拟文件系统（NVFS）。
This means that different virtual hosts cannot offer different virtual file systems to clients, nor can they offer different authentication systems. Any scheme to overcome this issue needs to indicate not only the destination IP address but also the virtual hostname that is associated with the desired virtual FTP server. Typical user-FTP processes currently use hostnames to perform hostname-to-IP-address resolution and then ignore hostnames for the
这意味着不同的虚拟主机不能向客户端提供不同的虚拟文件系统，也不能提供不同的身份验证系统。任何解决此问题的方案不仅需要指示目标IP地址，还需要指示与所需虚拟FTP服务器关联的虚拟主机名。典型的用户FTP进程当前使用主机名执行主机名到IP地址的解析，然后忽略主机名
rest of the FTP session; therefore, any mechanism to overcome this issue would require modifications to the user protocol interpreter (user-PI) and server protocol interpreter (server-PI).
FTP会话的其余部分；因此，任何克服此问题的机制都需要修改用户协议解释器（user PI）和服务器协议解释器（server PI）。
It should be noted that this same problem existed for HTTP/1.0 as defined in [RFC1945] and was resolved in HTTP/1.1 as defined in [RFC2616] through the addition of the Host request header field. The goal of this document is to bring a similar level of feature parity to FTP by introducing a new HOST command that allows user-FTP processes to specify which virtual host to connect to for a server-FTP process that is handling requests for multiple virtual hosts on a single IP address.
应该注意的是，HTTP/1.0存在[RFC1945]中定义的相同问题，并通过添加主机请求头字段在[RFC2616]中定义的HTTP/1.1中得到解决。本文档的目标是通过引入一个新的HOST命令，让用户FTP进程为处理单个IP地址上多个虚拟主机请求的服务器FTP进程指定要连接的虚拟主机，从而为FTP带来类似级别的功能奇偶校验。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
In examples, "C>" and "S>" indicate lines sent by the client and server, respectively.
在示例中，“C>”和“S>”分别表示客户端和服务器发送的行。
This document also uses notation defined in [RFC959] and [RFC1123]. In particular, the terms "reply", "user", "NVFS", "NVT", "file", "pathname", "FTP commands", "DTP", "user-FTP process", "user-PI", "user-DTP", "server-FTP process", "server-PI", "server-DTP", "mode", "type", "control connection", "data connection", and "ASCII", are all used here as defined there.
本文件还使用了[RFC959]和[RFC1123]中定义的符号。具体而言，术语“回复”、“用户”、“NVFS”、“NVT”、“文件”、“路径名”、“FTP命令”、“DTP”、“用户FTP进程”、“用户PI”、“用户DTP”、“服务器FTP进程”、“服务器PI”、“服务器DTP”、“模式”、“类型”、“控制连接”、“数据连接”和“ASCII”在此处均按此处定义使用。
The required syntax is defined using the Augmented BNF defined in [RFC5234]. Some general ABNF definitions are required throughout the document; they will be defined in subsequent sections.
使用[RFC5234]中定义的扩充BNF定义所需的语法。在整个文件中需要一些通用ABNF定义；它们将在后续章节中定义。
With the increased use of virtualization technologies, there may be several possible definitions for the term "virtual host". This document follows the definition from Section 4.1.14 of [RFC3875], where several virtual hosts share the same IP address, and hostnames are used by the server-FTP process to route user-PI sessions to the appropriate virtual host.
随着虚拟化技术使用的增加，“虚拟主机”一词可能有几种定义。本文档遵循[RFC3875]第4.1.14节的定义，其中多个虚拟主机共享相同的IP地址，服务器FTP进程使用主机名将用户PI会话路由到相应的虚拟主机。
This document imports the core definitions given in Appendix B of [RFC5234]. There, definitions will be found for basic ABNF elements like ALPHA, DIGIT, SP, etc. To that, the following term is added for use in this document.
本文件导入了[RFC5234]附录B中给出的核心定义。在这里，可以找到基本ABNF元素的定义，如ALPHA、DIGIT、SP等。除此之外，本文档中还添加了以下术语。
TCHAR = VCHAR / SP / HTAB ; visible plus white space
TCHAR = VCHAR / SP / HTAB ; visible plus white space
The VCHAR (from [RFC5234]) and TCHAR rules give basic character types from varying subsets of the ASCII character set for use in various commands and responses.
VCHAR（来自[RFC5234]）和TCHAR规则从ASCII字符集的不同子集中提供基本字符类型，用于各种命令和响应。
Note that in ABNF, string literals are case insensitive. That convention is preserved in this document and implies that FTP commands and parameters that are added by this specification have values that can be represented in any case. That is, "HOST" is the same as "host", "Host", "HoSt", etc. Similarly, because domain names are defined to be case insensitive, "ftp.example.com" is the same as "Ftp.Example.Com", "fTp.eXample.cOm", etc.
请注意，在ABNF中，字符串文字不区分大小写。该约定保留在本文档中，并意味着本规范添加的FTP命令和参数具有在任何情况下都可以表示的值。也就是说，“主机”与“主机”、“主机”、“主机”等相同。同样，由于域名定义为不区分大小写，“ftp.example.com”与“ftp.example.com”、“ftp.example.com”等相同。
Section 4.2 of [RFC959] defines the format and meaning of replies by the server-PI to FTP commands from the user-PI. Those reply conventions are used here without change.
[RFC959]第4.2节定义了服务器PI对来自用户PI的FTP命令的回复的格式和含义。这些回复约定在这里使用，没有任何更改。
error-response = error-code SP *TCHAR CRLF
error-code = ("4" / "5") 2DIGIT
error-response = error-code SP *TCHAR CRLF
error-code = ("4" / "5") 2DIGIT
Implementers should note that the ABNF syntax used in this document and other FTP-related documents (but that was not used in [RFC959]) sometimes shows replies using the one-line format. Unless otherwise explicitly stated, multi-line responses are also permitted. Implementers should assume that, unless stated to the contrary, any reply to any FTP command (including QUIT) can be of the multi-line format described in [RFC959].
实施者应注意，本文档和其他FTP相关文档中使用的ABNF语法（但[RFC959]中未使用）有时显示使用单行格式的回复。除非另有明确说明，否则也允许多行响应。实施者应假设，除非另有说明，对任何FTP命令（包括QUIT）的任何回复都可以是[RFC959]中描述的多行格式。
Throughout this document, replies will be identified by the three-digit code that is their first element. Thus, the term "500 reply" means a reply from the server-PI using the three-digit code "500".
在本文件中，答复将以三位数代码标识，这是答复的第一个要素。因此，术语“500应答”是指来自服务器PI的使用三位数代码“500”的应答。
A new command, "HOST", is added to the FTP command set in order to allow a server-FTP process to determine to which of possibly many virtual hosts the client wishes to connect. If a HOST command is sent, it MUST be issued before the user is authenticated, as this will allow the authentication scheme and set of authorized users to be dependent upon the virtual host that is chosen.
FTP命令集中添加了一个新命令“HOST”，以允许服务器FTP进程确定客户端希望连接到可能多个虚拟主机中的哪一个。如果发送主机命令，则必须在对用户进行身份验证之前发出该命令，因为这将允许身份验证方案和授权用户集依赖于所选的虚拟主机。
Server-FTP processes MUST treat a situation in which the HOST command is issued more than once before the user has been authenticated as though only the last HOST command had been sent, and return the appropriate reply for the last HOST command. Server-FTP processes
服务器FTP进程必须将在对用户进行身份验证之前多次发出主机命令的情况视为仅发送了最后一个主机命令，并为最后一个主机命令返回相应的答复。服务器FTP进程
MUST treat a situation in which the HOST command is issued after the user has been authenticated as an erroneous sequence of commands and return a 503 reply.
必须将在用户经过身份验证后发出主机命令的情况视为错误的命令序列，并返回503回复。
Servers should note that the response to the HOST command is a sensible time to send their "welcome" message. This allows the message to be personalized for any virtual hosts that are supported. It also allows the client to determine, via the FEAT response, the languages or representations supported by the server and select an appropriate one via the LANG command. See [RFC2640] for more information.
服务器应该注意，对HOST命令的响应是发送“欢迎”消息的合理时机。这允许针对任何受支持的虚拟主机对消息进行个性化处理。它还允许客户端通过FEAT响应确定服务器支持的语言或表示，并通过LANG命令选择适当的语言或表示。有关更多信息，请参阅[RFC2640]。
It should be noted that user-PI implementations that were created before the introduction of the HOST command will not support this new command. A similar problem existed with the introduction of the Host header for HTTP in [RFC2616], and HTTP server implementations had to determine how best to accommodate HTTP requests from down-level clients that did not support the Host header. With this in mind, server-FTP processes will need to determine how best to accommodate FTP requests from down-level FTP clients that do not support the HOST command, but those considerations are outside the scope of this document.
应该注意，在引入HOST命令之前创建的用户PI实现将不支持此新命令。[RFC2616]中引入HTTP的主机头也存在类似的问题，HTTP服务器实现必须确定如何最好地容纳来自不支持主机头的底层客户端的HTTP请求。考虑到这一点，服务器FTP进程将需要确定如何最好地容纳来自不支持HOST命令的底层FTP客户端的FTP请求，但这些注意事项不在本文档的范围之内。
The HOST command is defined as follows. Note that [RFC3986] remains the normative specification for the syntactic form of IPv4 and IPv6 address literals, in order to ensure identical presentation in 'ftp' URI hostname parts and in the protocol element specified here.
主机命令的定义如下。请注意，[RFC3986]仍然是IPv4和IPv6地址文本语法形式的标准规范，以确保在“ftp”URI主机名部分和此处指定的协议元素中呈现相同。
host-command = "HOST" SP hostname CRLF hostname = domain / IP-literal
host command=“host”SP hostname CRLF hostname=域/IP文本
domain = sub-domain *("." sub-domain)
sub-domain = let-dig [ldh-str]
let-dig = ALPHA / DIGIT
ldh-str = *( ALPHA / DIGIT / "-" ) let-dig
domain = sub-domain *("." sub-domain)
sub-domain = let-dig [ldh-str]
let-dig = ALPHA / DIGIT
ldh-str = *( ALPHA / DIGIT / "-" ) let-dig
IP-literal = ( "[" IPv6address "]" ) / IPv4address
IP-literal = ( "[" IPv6address "]" ) / IPv4address
IPv6address = <see [RFC3986] Section 3.2.2>
IPv4address = <see [RFC3986] Section 3.2.2>
IPv6address = <see [RFC3986] Section 3.2.2>
IPv4address = <see [RFC3986] Section 3.2.2>
host-response = host-ok / error-response
host-ok = "220" [ SP *TCHAR ] CRLF
host-response = host-ok / error-response
host-ok = "220" [ SP *TCHAR ] CRLF
The "hostname" rule is a restricted form of the "host" rule specified in [RFC3986]. Details of the additional restrictions imposed by this document are given in the discussion of the syntax that occurs later in this section; they aim at simplifying implementations by only allowing what currently is specified precisely and in use on the Internet.
“主机名”规则是[RFC3986]中指定的“主机”规则的限制形式。本节后面对语法的讨论中给出了本文件施加的附加限制的详细信息；他们的目标是通过只允许当前在互联网上精确指定和使用的内容来简化实现。
As with all FTP commands, the "HOST" command word is case independent and can be specified in any character case desired.
与所有FTP命令一样，“主机”命令字与大小写无关，可以在任何需要的字符大小写中指定。
The "hostname" (given as a parameter) specifies the virtual host to which access is desired. This SHOULD be the same hostname that was used to obtain the IP address to which the FTP control connection was made, after any client conversions have been completed that convert an abbreviated or local alias to a complete (fully qualified) domain name, but before resolving a DNS alias (owner of a CNAME resource record) to its canonical name.
“主机名”（作为参数提供）指定需要访问的虚拟主机。在完成将缩写或本地别名转换为完整（完全限定）域名的任何客户端转换之后，但在将DNS别名（CNAME资源记录的所有者）解析为其规范名称之前，此主机名应与用于获取FTP控制连接的IP地址的主机名相同。
Internationalization of domain names is only supported through the use of Internationalized Domain Names for Applications (IDNA) "A-labels" for <sub-domain> as described in [RFC5890]. For example, the following HOST command specifies an internationalized domain name:
域名国际化仅通过使用[RFC5890]中所述的应用程序国际化域名（IDNA）“A-标签”来支持<sub-domain>。例如，以下主机命令指定国际化域名：
HOST xn--e1afmkfd.com
主机xn--e1afmkfd.com
If the user was given an IPv4 or IPv6 literal address, and consequently was not required to derive the literal address from a hostname, the client MAY send the HOST command with the IPv4 or IPv6 literal address as specified to it. While it may seem counterintuitive to specify a literal address by using the HOST command after the client has already connected to the server using a literal address, this should be expected behavior because a user-FTP process should not be required to differentiate between a fully qualified domain name and an IPv4 or IPv6 network literal address. That being said, if the IPv4 or IPv6 literal address specified by the client does not match the literal address for the server, the server MUST respond with a 504 reply to indicate that the IPv4 or IPv6 literal address is not valid.
如果为用户提供了IPv4或IPv6文本地址，因此不需要从主机名派生文本地址，则客户端可以发送主机命令，其中包含指定给它的IPv4或IPv6文本地址。虽然在客户机已经使用文本地址连接到服务器之后，使用HOST命令指定文本地址似乎有违直觉，这应该是预期的行为，因为不需要用户FTP进程来区分完全限定的域名和IPv4或IPv6网络文本地址。也就是说，如果客户端指定的IPv4或IPv6文本地址与服务器的文本地址不匹配，则服务器必须以504回复进行响应，以指示IPv4或IPv6文本地址无效。
When the hostname parameter contains a literal address, square brackets are expected to disambiguate IPv6 address syntax from port numbers syntax. Therefore, if the literal address is an IPv6 address, the IPv6 address is required to be enclosed in square brackets (after eliminating any syntax that might also -- but is not required to -- be enclosed in brackets, and from which the server deduced that a literal address had been specified). For example, the
当hostname参数包含文本地址时，方括号将消除IPv6地址语法与端口号语法之间的歧义。因此，如果文本地址是IPv6地址，则需要将IPv6地址括在方括号中（在消除任何可能（但不需要）括在方括号中的语法后，服务器由此推断已指定了文本地址）。例如
following examples MAY be sent if the client had been instructed to connect to "192.0.2.1", "2001:db8::c000:201", or "::192.0.2.1", respectively, and IPv6 syntax is preferred:
如果已指示客户端分别连接到“192.0.2.1”、“2001:db8:：c000:201”或“：：192.0.2.1”，则可以发送以下示例，并且首选IPv6语法：
HOST 192.0.2.1
HOST [2001:db8::c000:201]
HOST [::192.0.2.1]
HOST 192.0.2.1
HOST [2001:db8::c000:201]
HOST [::192.0.2.1]
The client MUST NOT send the port number as part of the HOST command, even when the client has been instructed to connect to a non-standard port. The reason for this requirement is that the user-PI will have established a connection to the server-PI before the HOST command is sent; therefore, specifying a different port with the HOST command has no meaning. For example, the server-PI MUST respond with a 501 reply if the client sends a HOST command with syntax like either of the following examples:
即使已指示客户端连接到非标准端口，客户端也不得将端口号作为主机命令的一部分发送。此要求的原因是，在发送主机命令之前，用户PI将已建立到服务器PI的连接；因此，使用HOST命令指定不同的端口没有意义。例如，如果客户端发送的主机命令的语法与以下示例之一类似，则服务器PI必须以501回复进行响应：
HOST 192.0.2.1:2112
HOST [2001:db8::c000:201]:2112
HOST 192.0.2.1:2112
HOST [2001:db8::c000:201]:2112
The hostname parameter is otherwise to be treated as a fully qualified domain name or relative name as those terms are defined in Section 3.1 of [RFC1034]. This implies that the name is to be treated as a case-independent string, meaning that uppercase ASCII characters are to be treated as equivalent to their corresponding lowercase ASCII characters but otherwise preserved as given. It also implies some limits on the length of the parameter and of the components that create its internal structure. Those limits are not altered in any way here.
否则，主机名参数将被视为完全限定的域名或相对名称，因为这些术语在[RFC1034]第3.1节中有定义。这意味着名称将被视为独立于大小写的字符串，这意味着大写ASCII字符将被视为与其对应的小写ASCII字符等效，但在其他情况下将按给定的方式保留。它还意味着对参数的长度和创建其内部结构的组件的长度有一些限制。这些限制在这里没有任何改变。
Neither [RFC1034] nor [RFC1035] imposes any other restrictions upon what kinds of names can be stored in the DNS. This specification, however, only allows the use of names that can be inferred from the ABNF grammar given for the "hostname". Similarly, this specification restricts address literals to the IPv4 and IPv6 address families well established on the Internet.
[RFC1034]和[RFC1035]均不对DNS中可以存储的名称类型施加任何其他限制。但是，该规范只允许使用可以从为“主机名”给定的ABNF语法推断出的名称。类似地，此规范将地址文本限制为在Internet上建立良好的IPv4和IPv6地址系列。
Upon receiving the HOST command, before authenticating the user-PI, a server-FTP process SHOULD validate that the hostname given represents a valid virtual host for that server and, if it is valid, establish the appropriate environment for that virtual host. The resultant actions needed to create that environment are not specified here and may range from doing nothing at all to performing a simple change of working directory, changing authentication schemes and/or username and password lists, or making much more elaborate state changes -- such as creating isolated environments for each FTP session.
在收到HOST命令后，在验证用户PI之前，服务器FTP进程应验证给定的主机名是否表示该服务器的有效虚拟主机，如果该主机名有效，则为该虚拟主机建立适当的环境。此处未指定创建该环境所需的结果操作，这些操作可能包括：不执行任何操作，执行简单的工作目录更改，更改身份验证方案和/或用户名和密码列表，或进行更详细的状态更改，例如为每个FTP会话创建隔离环境。
The 220 reply code for the HOST command is the same as the code that is used in the initial "welcome" message that is sent after the connection is established.
主机命令的220回复代码与建立连接后发送的初始“欢迎”消息中使用的代码相同。
If the hostname specified would normally be acceptable, but is temporarily unavailable, the server-FTP process SHOULD respond to the HOST command with a 421 reply and close the connection.
如果指定的主机名通常是可接受的，但暂时不可用，则服务器FTP进程应以421回复主机命令并关闭连接。
Example:
例子：
The server-FTP process is shutting down, so the server-FTP process responds to the HOST command with a 421 reply and closes the connection. In this scenario, the 421 reply informs the client it can retry at another time.
服务器FTP进程正在关闭，因此服务器FTP进程以421应答响应主机命令并关闭连接。在这种情况下，421应答通知客户机可以在其他时间重试。
If the hostname specified is unknown at the server, or if the server is otherwise unwilling to treat the particular connection as a connection to the hostname specified, the server SHOULD respond with a 504 reply.
如果指定的主机名在服务器上未知，或者如果服务器不愿意将特定连接视为与指定主机名的连接，则服务器应以504回复进行响应。
Examples:
示例：
The particular virtual host that was specified by the HOST command is disabled at the server. The server responds with a 504 reply and keeps the connection open in order to allow the user-PI an opportunity to specify another virtual host with a subsequent HOST command.
由host命令指定的特定虚拟主机在服务器上被禁用。服务器以504应答进行响应，并保持连接打开，以便允许用户PI有机会使用后续主机命令指定另一个虚拟主机。
Alternatively, the server-FTP process might choose to route all connections with unknown hostnames to a different virtual host so that no connection attempts will result in failed connections. This design would be implementation specific and outside the scope of this specification.
或者，服务器FTP进程可能会选择将具有未知主机名的所有连接路由到不同的虚拟主机，以便任何连接尝试都不会导致连接失败。此设计将是特定于实现的，不在本规范的范围内。
As specified in [RFC959], the REIN command returns the state of the connection to what it was immediately after the transport connection was opened. This specification makes no changes to that behavior. The effect of a HOST command MUST be reset if a REIN command is performed, and a new HOST command MUST be issued afterwards in order to connect to a virtual host.
如[RFC959]中所述，REIN命令将连接状态返回到传输连接打开后的状态。本规范不对该行为进行任何更改。如果执行REIN命令，则必须重置主机命令的效果，然后必须发出新的主机命令才能连接到虚拟主机。
A user-PI MUST send the HOST command after opening the transport connection, or after any REIN command, before attempting to authenticate the user with the USER command. The following example illustrates what a typical login sequence might look like when the HOST command is used:
用户PI必须在打开传输连接后或在任何REIN命令后发送HOST命令，然后才能尝试使用user命令对用户进行身份验证。以下示例说明了使用HOST命令时典型登录序列的外观：
C> HOST ftp.example.com S> 220 Host accepted C> USER foo S> 331 Password required C> PASS bar S> 230 User logged in
C> 主机ftp.example.com S>220主机接受C>USER foo S>331所需密码C>PASS bar S>230用户登录
If a user-PI sends an additional HOST command before attempting to authenticate the user, a server-FTP process MUST treat the additional HOST command as though a previous HOST command was not sent and return the appropriate reply for the new HOST command. For example, if a user specifies the wrong virtual hostname by mistake, sending a subsequent HOST command will rectify the error. The following example illustrates what the login sequence might look like when the HOST command is sent twice before a user has been authenticated:
如果用户PI在尝试对用户进行身份验证之前发送附加主机命令，则服务器FTP进程必须将附加主机命令视为未发送以前的主机命令，并为新主机命令返回相应的答复。例如，如果用户错误地指定了错误的虚拟主机名，则发送后续主机命令将纠正错误。以下示例说明了在对用户进行身份验证之前发送两次主机命令时，登录序列可能是什么样子：
C> HOST foo.example.com S> 220 Host accepted C> HOST bar.example.com S> 220 Host accepted C> USER foo S> 331 Password required C> PASS bar S> 230 User logged in
C> HOST foo.example.com S>220主机接受的C>HOST bar.example.com S>220主机接受的C>USER foo S>331所需密码C>PASS bar S>230用户登录
The HOST command can be used in combination with the ACCT command to differentiate between a user's various accounts on a specific virtual host. In this scenario, the user-PI sends a HOST command, which the server-PI uses to route activity to the correct virtual host; the user-PI sends credentials using the USER and PASS commands, which the server-PI validates; then, the user-PI sends an ACCT command to specify any additional account information for the server-PI implementation. The following example illustrates a sequential series of client commands that specify both a HOST and ACCT, with the server responses omitted for brevity:
HOST命令可与ACCT命令结合使用，以区分特定虚拟主机上用户的各种帐户。在这个场景中，用户PI发送一个HOST命令，服务器PI使用该命令将活动路由到正确的虚拟主机；用户PI使用user和PASS命令发送凭证，服务器PI对此进行验证；然后，用户PI发送ACCT命令，为服务器PI实现指定任何其他帐户信息。以下示例演示了一系列连续的客户端命令，这些命令同时指定主机和帐户，为简洁起见，省略了服务器响应：
C> HOST ftp.example.com C> USER foo C> PASS bar C> ACCT project1
C> 主机ftp.example.com C>USER foo C>PASS bar C>ACCT project1
This is also true when the HOST command is used with the AUTH and ADAT commands that are discussed in [RFC2228] and [RFC4217]. In this scenario, the user-PI sends a HOST command, which the server-PI uses to route activity to the correct virtual host; then, the user-PI uses the AUTH and ADAT commands to negotiate the security mechanism and relevant authentication token(s) with the server-PI; then, the user-PI sends user credentials using the USER and PASS commands, which the server-PI validates, after which the user-PI MAY send an ACCT command to specify any additional account information for the server-PI implementation. The following example illustrates a sequential series of client commands that specify both HOST and ACCT commands when used in conjunction with the security commands that are discussed in [RFC2228] and [RFC4217], with the server responses omitted for brevity:
当HOST命令与[rfc228]和[RFC4217]中讨论的AUTH和ADAT命令一起使用时，也是如此。在这个场景中，用户PI发送一个HOST命令，服务器PI使用该命令将活动路由到正确的虚拟主机；然后，用户PI使用AUTH和ADAT命令与服务器PI协商安全机制和相关认证令牌；然后，用户PI使用user和PASS命令发送用户凭证，服务器PI对此进行验证，之后用户PI可以发送ACCT命令来指定服务器PI实现的任何附加帐户信息。以下示例说明了一系列连续的客户端命令，当与[RFC2228]和[RFC4217]中讨论的安全命令一起使用时，这些命令同时指定主机和ACCT命令，为简洁起见，省略了服务器响应：
C> HOST ftp.example.com
C> AUTH <mechanism-name>
C> ADAT <base64data>
C> USER foo
C> PASS bar
C> ACCT project1
C> HOST ftp.example.com
C> AUTH <mechanism-name>
C> ADAT <base64data>
C> USER foo
C> PASS bar
C> ACCT project1
An exception to the above scenario would be when a user-PI is providing the hostname in the "server_name" extension of a Transport Layer Security (TLS) extended client hello as discussed in [RFC6066]. When the user-PI specifies the hostname in the "server_name" extension of a TLS extended client hello, the server-PI MUST verify that the hostname in the HOST command matches the value of the "server_name" extension. The following example illustrates a sequential series of client commands that specify the HOST command when used in conjunction with the TLS extensions that are discussed in [RFC6066], with the server responses omitted for brevity:
上述场景的一个例外情况是，用户PI在传输层安全性（TLS）扩展客户端hello的“服务器名称”扩展中提供主机名，如[RFC6066]中所述。当用户PI在TLS扩展客户机hello的“server\u name”扩展中指定主机名时，服务器PI必须验证HOST命令中的主机名是否与“server\u name”扩展的值匹配。以下示例说明了一系列连续的客户端命令，这些命令在与[RFC6066]中讨论的TLS扩展一起使用时指定主机命令，为简洁起见，省略了服务器响应：
C> AUTH TLS C> HOST ftp.example.com C> USER foo C> PASS bar
C> AUTH TLS C>HOST ftp.example.com C>USER foo C>PASS bar
Additional security information about using the HOST command with the security extensions that are discussed in [RFC2228], [RFC4217], and [RFC6066] is provided in Section 4 of this document.
本文档第4节提供了有关在[RFC2228]、[RFC4217]和[RFC6066]中讨论的安全扩展中使用HOST命令的其他安全信息。
The state diagrams in this section illustrate typical sequences for command and reply interchange between the user-PI and server-PI. These diagrams are modeled on the similar diagrams in Section 6 of [RFC959].
本节中的状态图说明了用户PI和服务器PI之间命令和应答交换的典型序列。这些图以[RFC959]第6节中的类似图为模型。
In each diagram, the (B) "begin" state is assumed to occur after the transport connection has opened or after a REIN command has succeeded. Other commands (such as FEAT [RFC2389]) that require no authentication may have intervened.
在每个图中，假定（B）“开始”状态发生在传输连接打开后或REIN命令成功后。不需要验证的其他命令（如FEAT[RFC2389]）可能已经介入。
Additionally, a three-digit reply indicates a precise server reply code. A single digit on a reply path indicates any server reply that begins with that digit, except where a precise server reply code is defined on another path. For example, a single digit "5" will apply to "500", "501", "502", etc., when those reply codes are not expressly defined in the diagram. For each command, there are three possible outcomes: success (S), failure (F), or error (E). In the state diagrams below, we use the symbol "B" for "begin" and the symbol "W" for "wait for reply".
此外，三位数的回复表示精确的服务器回复代码。回复路径上的单个数字表示以该数字开头的任何服务器回复，除非在另一个路径上定义了精确的服务器回复代码。例如，当这些应答码在图中没有明确定义时，单个数字“5”将应用于“500”、“501”、“502”等。对于每个命令，都有三种可能的结果：成功（S）、失败（F）或错误（E）。在下面的状态图中，我们使用符号“B”表示“开始”，使用符号“W”表示“等待答复”。
For each of these diagrams, without any state transitions being shown, a REIN command will return the diagram from any wait state to the (B) "begin" state.
对于这些图中的每个图，在不显示任何状态转换的情况下，REIN命令会将图从任何等待状态返回到（B）“开始”状态。
The state diagram in Figure 1 shows a typical sequence of flow of control when HOST is used with USER and PASS to log in to a particular FTP virtual host.
图1中的状态图显示了主机与用户一起使用并传递以登录到特定FTP虚拟主机时的典型控制流序列。
+---+ HOST +---+ 1,3,5
| B |---------->| W |-----------------
+---+ +---+ |
| | |
2,500,502 | | 4,501,503,504 |
-------------- ----------- |
| | V
V 1 | +---+
+---+ USER +---+-------------->| E |
| |---------->| W | 2 | +---+
+---+ +---+------- | ^
| | | | |
3 | | 4,5 | | |
-------------- ----- | | |
| | | | |
| -------------------
| 1| | | |
V | | ------>+---+
+---+ PASS +---+ 2 | | | S |
| |---------->| W |-------------->+---+
+---+ +---+ | |
| | |
|4,5 | |
| | --->+---+
| --------->| F |
---------------->+---+
+---+ HOST +---+ 1,3,5
| B |---------->| W |-----------------
+---+ +---+ |
| | |
2,500,502 | | 4,501,503,504 |
-------------- ----------- |
| | V
V 1 | +---+
+---+ USER +---+-------------->| E |
| |---------->| W | 2 | +---+
+---+ +---+------- | ^
| | | | |
3 | | 4,5 | | |
-------------- ----- | | |
| | | | |
| -------------------
| 1| | | |
V | | ------>+---+
+---+ PASS +---+ 2 | | | S |
| |---------->| W |-------------->+---+
+---+ +---+ | |
| | |
|4,5 | |
| | --->+---+
| --------->| F |
---------------->+---+
Figure 1: Typical Login Sequence with HOST Command
图1：使用HOST命令的典型登录序列
After a user has logged in, an additional account may be required by the server and specified by the client by using the ACCT command. With this in mind, the state diagram in Figure 2 shows a typical sequence of flow of control when HOST is used with USER and PASS to log in to an FTP virtual host and ACCT is used to specify an account.
用户登录后，服务器可能需要一个额外的帐户，客户端可以使用ACCT命令指定该帐户。考虑到这一点，图2中的状态图显示了一个典型的控制流序列，当主机与用户一起使用时，PASS登录到FTP虚拟主机，ACCT用于指定帐户。
+---+ HOST +---+ 1,3,5
| B |---------->| W |-----------------
+---+ +---+ |
| | |
2,500,502 | | 4,501,503,504 |
-------------- ------------- |
| | |
V 1 | V
+---+ USER +---+-------------->+---+
| |---------->| W | 2 ----->| E |
+---+ +---+------ | --->+---+
| | | | | |
3 | | 4,5 | | | |
-------------- ----- | | | |
| | | | | |
| | | | | |
| ---------- | |
| 1| | | | |
V | | | | |
+---+ PASS +---+ 2 | ------->+---+
| |---------->| W |-------------->| S |
+---+ +---+ ----------->+---+
| | | | | |
3 | |4,5| | | |
-------------- -------- | ----
| | | | | |
| | | | | |
| ------------ |
| 1,3| | | | |
V | 2| | | V
+---+ ACCT +---+-- | ------>+---+
| |---------->| W | 4,5 --------->| F |
+---+ +---+-------------->+---+
+---+ HOST +---+ 1,3,5
| B |---------->| W |-----------------
+---+ +---+ |
| | |
2,500,502 | | 4,501,503,504 |
-------------- ------------- |
| | |
V 1 | V
+---+ USER +---+-------------->+---+
| |---------->| W | 2 ----->| E |
+---+ +---+------ | --->+---+
| | | | | |
3 | | 4,5 | | | |
-------------- ----- | | | |
| | | | | |
| | | | | |
| ---------- | |
| 1| | | | |
V | | | | |
+---+ PASS +---+ 2 | ------->+---+
| |---------->| W |-------------->| S |
+---+ +---+ ----------->+---+
| | | | | |
3 | |4,5| | | |
-------------- -------- | ----
| | | | | |
| | | | | |
| ------------ |
| 1,3| | | | |
V | 2| | | V
+---+ ACCT +---+-- | ------>+---+
| |---------->| W | 4,5 --------->| F |
+---+ +---+-------------->+---+
Figure 2: Login Sequence with HOST and ACCT Commands
图2:HOST和ACCT命令的登录顺序
The state diagram in Figure 3 shows a typical sequence of flow of control when HOST is used with the AUTH and ADAT commands that are discussed in [RFC2228]. (NOTE: Section 4 provides additional information about using the HOST command with TLS.)
图3中的状态图显示了主机与[RFC2228]中讨论的AUTH和ADAT命令一起使用时的典型控制流序列。（注意：第4节提供了有关在TLS中使用HOST命令的其他信息。）
+---+ HOST +---+ 1,3,5
| B |---------->| W |------------------
+---+ +---+ |
| | |
2,500,502 | | 4,501,503,504 |
-------------- ------------- |
| | |
V | |
+---+ AUTH +---+ 4,5 | |
| |---------->| W |----------->| |
+---+ +---+ | |
334 | | | |
-------------- | | |
| 234 | | |
| ------------ | |
V | 4,5 | |
+---+ | ADAT +---+----------->| |
| |---------->| W | 335 | |
+---+ | +---+----- | |
^ | | | | |
| | | | | |
----------------------- | |
| | | |
---- 235 | | |
| -------------- | |
| | | V
V V 1 | +---+
+---+ USER +---+--------------->| E |
| |---------->| W | 2 | +---+
+---+ +---+------- | ^
| | | | |
3 | | 4,5 | | |
-------------- ------ | | |
| | | | |
| --------------------
| 1| | | |
V | | ------->+---+
+---+ PASS +---+ 2 | | | S |
| |---------->| W |--------------->+---+
+---+ +---+ | |
| | |
|4,5 | |
| | -->+---+
| --------->| F |
----------------->+---+
+---+ HOST +---+ 1,3,5
| B |---------->| W |------------------
+---+ +---+ |
| | |
2,500,502 | | 4,501,503,504 |
-------------- ------------- |
| | |
V | |
+---+ AUTH +---+ 4,5 | |
| |---------->| W |----------->| |
+---+ +---+ | |
334 | | | |
-------------- | | |
| 234 | | |
| ------------ | |
V | 4,5 | |
+---+ | ADAT +---+----------->| |
| |---------->| W | 335 | |
+---+ | +---+----- | |
^ | | | | |
| | | | | |
----------------------- | |
| | | |
---- 235 | | |
| -------------- | |
| | | V
V V 1 | +---+
+---+ USER +---+--------------->| E |
| |---------->| W | 2 | +---+
+---+ +---+------- | ^
| | | | |
3 | | 4,5 | | |
-------------- ------ | | |
| | | | |
| --------------------
| 1| | | |
V | | ------->+---+
+---+ PASS +---+ 2 | | | S |
| |---------->| W |--------------->+---+
+---+ +---+ | |
| | |
|4,5 | |
| | -->+---+
| --------->| F |
----------------->+---+
Figure 3: Login Sequence with HOST and AUTH/ADAT Commands
图3:HOST和AUTH/ADAT命令的登录顺序
After a user has logged in with the security commands that are discussed in [RFC2228], an additional account may be required by the server and specified by the client by using the ACCT command. The state diagram in Figure 4 shows a typical sequence of flow of control when HOST is used with the AUTH and ADAT commands to log in to an FTP virtual host and ACCT is used to specify an account.
用户使用[RFC2228]中讨论的安全命令登录后，服务器可能需要一个额外的帐户，客户机可以使用ACCT命令指定该帐户。图4中的状态图显示了当主机与AUTH和ADAT命令一起使用以登录到FTP虚拟主机并使用ACCT指定帐户时的典型控制流序列。
+---+ HOST +---+ 1,3,5
| B |---------->| W |------------------
+---+ +---+ |
| | |
2,500,502 | | 4,501,503,504 |
+-------------- -------------- |
| | |
V | |
+---+ AUTH +---+ 4,5 | |
| |---------->| W |------------>| |
+---+ +---+ | |
334 | | | |
-------------- | | |
| 234 | | |
| ------------ | |
V | 4,5 | |
+---+ | ADAT +---+------------>| |
| |---------->| W | 335 | |
+---+ | +---+----- | |
^ | | | | |
| | | | | |
----------------------- | |
| | | |
---- 235| | |
| -------------- | |
| | | |
V V 1 | V
+---+ USER +---+--------------->+---+
| |---------->| W | 2 ----->| E |
+---+ +---+------- | --->+---+
| | | | | |
3 | | 4,5 | | | |
-------------- ------ | | | |
| | | | | |
| ----------- | |
| 1| | | | |
V | | | | |
+---+ PASS +---+ 2 | ------->+---+
| |---------->| W |--------------->| S |
+---+ +---+ ------------>+---+
| | | | | |
+---+ HOST +---+ 1,3,5
| B |---------->| W |------------------
+---+ +---+ |
| | |
2,500,502 | | 4,501,503,504 |
+-------------- -------------- |
| | |
V | |
+---+ AUTH +---+ 4,5 | |
| |---------->| W |------------>| |
+---+ +---+ | |
334 | | | |
-------------- | | |
| 234 | | |
| ------------ | |
V | 4,5 | |
+---+ | ADAT +---+------------>| |
| |---------->| W | 335 | |
+---+ | +---+----- | |
^ | | | | |
| | | | | |
----------------------- | |
| | | |
---- 235| | |
| -------------- | |
| | | |
V V 1 | V
+---+ USER +---+--------------->+---+
| |---------->| W | 2 ----->| E |
+---+ +---+------- | --->+---+
| | | | | |
3 | | 4,5 | | | |
-------------- ------ | | | |
| | | | | |
| ----------- | |
| 1| | | | |
V | | | | |
+---+ PASS +---+ 2 | ------->+---+
| |---------->| W |--------------->| S |
+---+ +---+ ------------>+---+
| | | | | |
3 | |4,5| | | |
-------------- --------- | ----
| | | | | |
| ------------- |
| 1,3| | | | |
V | 2| | | V
+---+ ACCT +---+-- | ------>+---+
| |---------->| W | 4,5 --------->| F |
+---+ +---+--------------->+---+
3 | |4,5| | | |
-------------- --------- | ----
| | | | | |
| ------------- |
| 1,3| | | | |
V | 2| | | V
+---+ ACCT +---+-- | ------>+---+
| |---------->| W | 4,5 --------->| F |
+---+ +---+--------------->+---+
Figure 4: Login Sequence with HOST and AUTH/ADAT/ACCT Commands
Figure 4: Login Sequence with HOST and AUTH/ADAT/ACCT Commands
The server-PI SHOULD return a 500 or 502 reply if the HOST command is unrecognized or unimplemented, as specified in [RFC959]. For example, a server-PI that predates or otherwise does not conform to this specification would be expected to return a 500 or 502 reply.
如[RFC959]中所述，如果主机命令无法识别或未实现，则服务器PI应返回500或502回复。例如，早于或不符合此规范的服务器PI将返回500或502回复。
As discussed in Section 3 of this document, if a HOST command is sent after a user has been authenticated, the server MUST treat the situation as an invalid sequence of commands and return a 503 reply.
如本文档第3节所述，如果在对用户进行身份验证后发送主机命令，则服务器必须将该情况视为无效的命令序列，并返回503回复。
A 501 reply SHOULD be sent if the hostname given is syntactically invalid, and a 504 reply SHOULD be sent if a syntactically valid hostname is not a valid virtual hostname for the server. In all such cases, the server-FTP process MUST do one of the following:
如果给定的主机名语法无效，则应发送501回复；如果语法有效的主机名不是服务器的有效虚拟主机名，则应发送504回复。在所有此类情况下，服务器FTP进程必须执行以下操作之一：
a. Ignore the HOST command and act as if a HOST command had not been sent. A user-FTP process MAY then send a subsequent HOST command with a different hostname.
a. 忽略主机命令，并将其视为尚未发送主机命令。然后，用户FTP进程可以发送具有不同主机名的后续主机命令。
b. Close the connection.
b. 关闭连接。
A user-PI receiving a 500 or 502 reply to a HOST command SHOULD assume that the server-PI does not implement virtual servers by using the HOST command. The user-PI MAY then proceed to log in as if the HOST command had not been sent.
接收到对主机命令的500或502回复的用户PI应该假设服务器PI没有使用主机命令实现虚拟服务器。然后，用户PI可以继续登录，就像主机命令尚未发送一样。
A user-PI receiving an error reply that is different from the errors that have been described here SHOULD assume that the virtual HOST is unavailable and terminate communications.
接收到不同于此处所述错误的错误回复的用户PI应假设虚拟主机不可用并终止通信。
A server-PI that receives a USER command to begin the authentication sequence without having received a HOST command SHOULD NOT reject the USER command. Clients that conform to earlier FTP specifications do not send HOST commands. In this case, the server MAY act as if some default virtual host had been explicitly selected, or the server MAY
在没有收到主机命令的情况下接收用户命令以开始身份验证序列的服务器PI不应拒绝该用户命令。符合早期FTP规范的客户端不发送主机命令。在这种情况下，服务器可能会表现为显式选择了某个默认虚拟主机，或者服务器可能会
enter an environment that is different from that of any supported virtual hosts, perhaps one in which a union of all available accounts exists and that presents an NVFS that appears to contain subdirectories that contain the NVFS for all supported virtual hosts.
进入一个不同于任何受支持虚拟主机的环境，可能是一个存在所有可用帐户联合的环境，该环境显示一个NVFS，其中似乎包含包含所有受支持虚拟主机的NVFS的子目录。
When replying to the FEAT command [RFC2389], a server-FTP process that supports the HOST command MUST include a line containing the single word "HOST". This word is case insensitive, but it SHOULD be sent in upper case so as to maximize interoperability with disparate implementations. That is, the response SHOULD be:
在响应FEAT命令[RFC2389]时，支持HOST命令的服务器FTP进程必须包含一行，其中包含单个单词“HOST”。这个词不区分大小写，但应该以大写字母发送，以便最大限度地提高与不同实现的互操作性。也就是说，答案应该是：
C> FEAT
S> 211- <any descriptive text>
S> ...
S> HOST
S> ...
S> 211 End
C> FEAT
S> 211- <any descriptive text>
S> ...
S> HOST
S> ...
S> 211 End
The ellipses indicate placeholders where other features may be included but are not required. The one-space indentation of the feature lines is mandatory [RFC2389].
省略号表示可能包含但不需要其他功能的占位符。要素线的单空间缩进是强制性的[RFC2389]。
As discussed in Section 3 of this document, a server implementation MUST treat an additional HOST command that was sent before a user has been authenticated as though a previous HOST command was not sent. In this situation, the server implementation MUST reset the authentication environment, as that would allow for segregation between the security environments for each virtual host on an FTP server. The implementation details for security environments may vary greatly based on the requirements of each server implementation and operating system, and those details are outside the scope of the protocol itself. For example, a virtual host "foo.example.com" on an FTP server might use a specific username and password list, while the virtual host "bar.example.com" on the same FTP server might use a different username and password list. In such a scenario, resetting the security environment is necessary for the virtual servers to appear to behave independently from a client perspective, while the actual server implementation details are irrelevant at the protocol level.
如本文档第3节所述，服务器实现必须将在对用户进行身份验证之前发送的附加主机命令视为未发送以前的主机命令。在这种情况下，服务器实现必须重置身份验证环境，因为这将允许在FTP服务器上每个虚拟主机的安全环境之间进行隔离。根据每个服务器实现和操作系统的要求，安全环境的实现细节可能会有很大差异，这些细节不在协议本身的范围之内。例如，FTP服务器上的虚拟主机“foo.example.com”可能使用特定的用户名和密码列表，而同一FTP服务器上的虚拟主机“bar.example.com”可能使用不同的用户名和密码列表。在这种情况下，重新设置安全环境是必要的，这样虚拟服务器就可以从客户端的角度独立运行，而实际的服务器实现细节在协议级别上是不相关的。
Section 15.1.1 of [RFC4217] discusses the use of X.509 certificates for server authentication. Taking the information from that document into account, when securing FTP sessions with the security mechanisms that are defined in [RFC4217], client implementations SHOULD verify
[RFC4217]的第15.1.1节讨论了使用X.509证书进行服务器身份验证。考虑到该文档中的信息，当使用[RFC4217]中定义的安全机制保护FTP会话时，客户端实现应验证
that the hostname that they specify in the parameter for the HOST command matches the identity that is specified in the server's X.509 certificate in order to prevent man-in-the-middle attacks.
他们在HOST命令的参数中指定的主机名与服务器的X.509证书中指定的标识匹配，以防止中间人攻击。
When the HOST command is used in combination with the FTP security extensions that were introduced in [RFC2228] and [RFC4217], the HOST command SHOULD precede the security handshake when the user-PI is not providing the "server_name" in the extended client hello as defined in [RFC6066]. This allows both user-FTP and server-FTP processes to map an FTP HOST with the correct server name in the server's certificate. If the HOST command is sent after the security handshake, then mapping an FTP HOST to the correct security certificate will not take place before the secure session is established.
当HOST命令与[RFC2228]和[RFC4217]中引入的FTP安全扩展结合使用时，当用户PI未提供[RFC6066]中定义的扩展客户端hello中的“服务器名称”时，HOST命令应先于安全握手。这允许用户FTP和服务器FTP进程使用服务器证书中的正确服务器名称映射FTP主机。如果主机命令是在安全握手之后发送的，则在建立安全会话之前，不会将FTP主机映射到正确的安全证书。
For example, if a server-FTP process has multiple virtual hosts defined and no hostname has been sent from a user-FTP process, the server-FTP process will be unable to route the connection to the correct virtual host when the connection is established. In this situation, the server-FTP process will be forced to choose a virtual host that will respond. When the user-PI attempts to negotiate a secure connection, the virtual host to which the connection was routed will respond with its server certificate during the security handshake. If the virtual host that was chosen by the server-FTP process does not match the virtual host to which the user-FTP process had intended to connect, the user-PI will be unable to verify the server's identity as presented in the server certificate message.
例如，如果服务器FTP进程定义了多个虚拟主机，并且没有从用户FTP进程发送主机名，则在建立连接时，服务器FTP进程将无法将连接路由到正确的虚拟主机。在这种情况下，服务器FTP进程将被迫选择一个将响应的虚拟主机。当用户PI尝试协商安全连接时，连接路由到的虚拟主机将在安全握手期间使用其服务器证书进行响应。如果服务器FTP进程选择的虚拟主机与用户FTP进程打算连接的虚拟主机不匹配，则用户PI将无法验证服务器证书消息中显示的服务器身份。
However, if the user-PI is providing the "server_name" in the extended client hello as defined in Section 3 of [RFC6066], the user-PI MAY provide the HOST command after the security handshake because the server will be able to route the connection to the correct virtual host based on the contents of the "server_name" extension and the client will be able to verify the server's identity as presented in the corresponding server certificate message. However, the server-PI MUST verify that the name in the HOST command matches the "server_name" that is provided in the extended client hello.
但是，如果用户PI在[RFC6066]第3节中定义的扩展客户端hello中提供“服务器\名称”，则用户PI可以在安全握手后提供主机命令，因为服务器将能够根据“服务器\名称”的内容将连接路由到正确的虚拟主机扩展和客户端将能够验证相应服务器证书消息中显示的服务器身份。但是，服务器PI必须验证HOST命令中的名称是否与扩展客户机hello中提供的“server_name”匹配。
In general, client implementations SHOULD protect user credentials by using the FTP security extensions that were introduced in [RFC2228] and [RFC4217]; a detailed discussion for securing FTP sessions can be found in those documents, and a general discussion of security issues related to FTP can be found in [RFC2577].
一般来说，客户端实现应该使用[RFC2228]和[RFC4217]中引入的FTP安全扩展来保护用户凭据；关于保护FTP会话的详细讨论可以在这些文档中找到，与FTP相关的安全问题的一般性讨论可以在[RFC2577]中找到。
IANA has registered the following FTP extension according to the procedure established by [RFC5797]:
IANA已根据[RFC5797]建立的程序注册了以下FTP扩展：
+------+---------+-------------+------+------+----------------------+
| cmd | FEAT | description | type | conf | RFC#s/References and |
| | Code | | | | Notes |
+------+---------+-------------+------+------+----------------------+
| HOST | HOST | Hostname | a | o | RFC 7151 |
+------+---------+-------------+------+------+----------------------+
+------+---------+-------------+------+------+----------------------+
| cmd | FEAT | description | type | conf | RFC#s/References and |
| | Code | | | | Notes |
+------+---------+-------------+------+------+----------------------+
| HOST | HOST | Hostname | a | o | RFC 7151 |
+------+---------+-------------+------+------+----------------------+
[RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, October 1985.
[RFC959]Postel，J.和J.Reynolds，“文件传输协议（FTP）”，标准9，RFC959，1985年10月。
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123]Braden，R.，“互联网主机的要求-应用和支持”，STD 3，RFC 1123，1989年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2228] Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC 2228, October 1997.
[RFC2228]Horowitz，M.和S.Lunt，“FTP安全扩展”，RFC2228，1997年10月。
[RFC2389] Hethmon, P. and R. Elz, "Feature negotiation mechanism for the File Transfer Protocol", RFC 2389, August 1998.
[RFC2389]Hethmon，P.和R.Elz，“文件传输协议的特征协商机制”，RFC 2389，1998年8月。
[RFC2640] Curtin, B., "Internationalization of the File Transfer Protocol", RFC 2640, July 1999.
[RFC2640]Curtin，B.，“文件传输协议的国际化”，RFC 26401999年7月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4217] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217, October 2005.
[RFC4217]Ford Hutchinson，P.，“使用TLS保护FTP”，RFC 42172005年10月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890]Klensin，J.，“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 58902010年8月。
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.
[RFC6066]Eastlake，D.，“传输层安全（TLS）扩展：扩展定义”，RFC6066，2011年1月。
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[RFC1945]Berners Lee，T.，Fielding，R.，和H.Nielsen，“超文本传输协议——HTTP/1.0”，RFC 1945，1996年5月。
[RFC2577] Allman, M. and S. Ostermann, "FTP Security Considerations", RFC 2577, May 1999.
[RFC2577]Allman，M.和S.Ostermann，“FTP安全注意事项”，RFC 2577，1999年5月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC3875] Robinson, D. and K. Coar, "The Common Gateway Interface (CGI) Version 1.1", RFC 3875, October 2004.
[RFC3875]Robinson，D.和K.Coar，“公共网关接口（CGI）1.1版”，RFC 3875，2004年10月。
[RFC5797] Klensin, J. and A. Hoenes, "FTP Command and Extension Registry", RFC 5797, March 2010.
[RFC5797]Klensin，J.和A.Hoenes，“FTP命令和扩展注册表”，RFC 57972010年3月。
Due to the level of scope for adding a new command to FTP, a brief discussion of suggested alternatives to a HOST command and their respective limitations is warranted. The suggested alternatives that are discussed in this appendix have been proposed in the past, but each of these ideas was deemed insufficient for the reasons listed within each section of this appendix.
由于向FTP添加新命令的范围很广，因此有必要对建议的主机命令替代方案及其各自的限制进行简要讨论。本附录中讨论的建议备选方案在过去已经提出，但由于本附录各节中列出的原因，这些想法中的每一个都被认为是不够的。
One suggested method to emulate a form of virtual hosts would be for the client to simply send a CWD command after connecting, using the virtual hostname as the argument to the CWD command. This would allow the server-FTP process to implement the file stores of the virtual hosts as subdirectories in its NVFS. This suggestion is simple in concept, and most server-FTP implementations support this without requiring any code changes. While this method is simple to describe and implement, it suffers from several drawbacks:
一种模拟虚拟主机形式的建议方法是，客户端在连接后只需发送一个CWD命令，使用虚拟主机名作为CWD命令的参数。这将允许服务器FTP进程将虚拟主机的文件存储实现为其NVFS中的子目录。这一建议在概念上很简单，大多数服务器FTP实现都支持这一点，而不需要任何代码更改。虽然该方法易于描述和实现，但存在以下几个缺点：
a. The CWD command is available only after the user-PI has authenticated itself to the server-FTP process. Thus, all virtual hosts would be required to share a common authentication scheme if they used this method.
a. CWD命令只有在用户PI向服务器FTP进程进行身份验证后才可用。因此，如果使用此方法，则所有虚拟主机都需要共享一个公共身份验证方案。
b. To make the virtual host truly transparent, either the server-FTP process needs to be modified to include information that shows the special nature of this first CWD command (negating most of the advantage of this scheme), or all users must see the same identical NVFS view upon connecting (they must connect in the same initial directory), or the NVFS must implement the full set of virtual host directories at each possible initial directory for any possible user.
b. 为了使虚拟主机真正透明，需要修改服务器FTP进程以包含显示第一个CWD命令的特殊性质的信息（否定此方案的大部分优点），或者所有用户在连接时必须看到相同的NVFS视图（他们必须在相同的初始目录中连接），或者，NVFS必须在每个可能的初始目录中为任何可能的用户实现全套虚拟主机目录。
c. Unless the server is specially modified, a user connecting this way to a virtual host would be able to easily move to any other virtual host supported at the same server-FTP process, exposing the nature of the virtual host.
c. 除非对服务器进行特殊修改，否则通过这种方式连接到虚拟主机的用户将能够轻松地移动到同一服务器FTP进程支持的任何其他虚拟主机，从而公开虚拟主机的性质。
Another suggested method would be to simply overload the ACCT command for FTP virtual hosts, but this proposal is unacceptable for several reasons with regard to when the ACCT command is sent during the request flow. Sections 5.4 and 6 of [RFC959] document the request flow for a login sequence as USER -> PASS -> ACCT. This flow of commands may be acceptable when you are considering a single user
另一种建议的方法是简单地为FTP虚拟主机重载ACCT命令，但由于在请求流期间何时发送ACCT命令的几个原因，这种建议是不可接受的。[RFC959]第5.4节和第6节记录了登录序列的请求流，即用户->通过->帐户。当您考虑单个用户时，可以接受此命令流
having multiple accounts on an FTP server, but it fails to differentiate between virtual hosts when you consider the following two issues:
在FTP服务器上有多个帐户，但当考虑以下两个问题时，它无法区分虚拟主机：
a. The first problem with overloading the ACCT command is certificate negotiation when using the FTP security extensions that are documented in [RFC2228] and [RFC4217]. In order to safeguard user credentials, negotiation of the security mechanism and certificate must occur before login credentials are sent by the client. The problem with using the ACCT command in this scenario is that there is no way of ensuring that the certificate matches the correct virtual host before the user credentials are sent.
a. 重载ACCT命令的第一个问题是在使用[RFC2228]和[RFC4217]中介绍的FTP安全扩展时进行证书协商。为了保护用户凭据，必须在客户端发送登录凭据之前协商安全机制和证书。在这种情况下使用ACCT命令的问题是，在发送用户凭据之前，无法确保证书与正确的虚拟主机匹配。
b. The second problem with overloading the ACCT command is how user credentials are implemented for FTP virtual hosts. FTP server implementations may allow the use of custom user credentials on a per-virtual-host basis. For example, in one particular implementation the virtual host negotiation occurs, and then the user credentials are looked up using the account mechanism that is specific to that virtual host. So once again the virtual host negotiation must take place before the user credentials are sent.
b. 重载ACCT命令的第二个问题是如何为FTP虚拟主机实现用户凭据。FTP服务器实现可能允许在每个虚拟主机上使用自定义用户凭据。例如，在一个特定实现中，虚拟主机协商发生，然后使用特定于该虚拟主机的帐户机制查找用户凭据。因此，在发送用户凭据之前，必须再次进行虚拟主机协商。
An additional suggestion would be to overload well-known syntax through the existing USER command, as illustrated in the following example:
另一个建议是通过现有用户命令重载已知语法，如以下示例所示：
C> USER foo@example.com S> 331 Password required C> PASS bar S> 230 User logged in
C> 使用者foo@example.comS>331所需密码C>PASS bar S>230用户登录
In this example, the user "foo" might be attempting to log on to the virtual host "example.com" on an FTP server. This suggestion may seem plausible at first, but it introduces several implementation problems. For example:
在本例中，用户“foo”可能正试图登录FTP服务器上的虚拟主机“example.com”。这一建议一开始似乎是合理的，但它引入了几个实现问题。例如：
a. Some network environments already use the "username@hostname" syntax for network credentials, where the "hostname" portion refers to the location of the user's credentials within the network hierarchy. Using the "foo@example.com" syntax, it becomes difficult to differentiate between the user "foo" logging into a virtual host that is named "example.com" on an FTP server versus the user "foo@example.com" logging into an FTP server with no specified virtual host.
a. 某些网络环境已使用“username@hostname网络凭据的语法，其中“主机名”部分指用户凭据在网络层次结构中的位置。使用“foo@example.com语法，很难区分登录FTP服务器上名为“example.com”的虚拟主机的用户“foo”和用户foo@example.com“登录到没有指定虚拟主机的FTP服务器。
b. When using the FTP security extensions that are documented in [RFC2228] and [RFC4217], negotiation of the security mechanism and certificate must occur before login credentials are sent by the client. More specifically, the AUTH/ADAT commands must be sent before the USER command in order to safeguard user credentials. If you overload the USER command, there is no way of ensuring that the certificate matches the correct virtual host before the user credentials are sent by the client.
b. 使用[RFC2228]和[RFC4217]中记录的FTP安全扩展时，必须在客户端发送登录凭据之前协商安全机制和证书。更具体地说，必须在用户命令之前发送AUTH/ADAT命令，以保护用户凭据。如果重载USER命令，则在客户端发送用户凭据之前，无法确保证书与正确的虚拟主机匹配。
After examining the above alternatives, and in order to obtain an adequate emulation of "real" FTP servers, it was concluded that supporting virtual hosts will require both client and server modifications. Therefore, a new FTP command seems the most likely solution to provide the required level of support.
在研究了上述备选方案之后，为了充分模拟“真实”FTP服务器，得出结论，支持虚拟主机需要修改客户端和服务器。因此，新的FTP命令似乎是最有可能提供所需支持级别的解决方案。
Robert Elz and Paul Hethmon provided a detailed discussion of the HOST command in their Internet-Draft titled "Extensions to FTP" as part of their work with the FTPEXT Working Group of the IETF. Their work formed the basis for much of this document, and their help has been greatly appreciated. They would also like to credit Bernhard Rosenkraenzer for having first suggested and described the HOST command.
Robert Elz和Paul Hethmon在其名为“FTP扩展”的互联网草案中详细讨论了主机命令，作为他们与IETF FTPEXT工作组合作的一部分。他们的工作构成了本文件大部分内容的基础，他们的帮助得到了极大的赞赏。他们还要感谢Bernhard Rosenkraenzer首先提出并描述了主机命令。
Several people have provided a wealth of constructive feedback about earlier versions of this document that has helped to shape its development; many of their suggestions have been incorporated, and their contributions are gratefully acknowledged. There are far too many to mention here, but the authors of this document would like to specifically thank Alexey Melnikov, Alfred Hoenes, John Klensin, Joe Touch, Paul Ford-Hutchinson, Daniel Stenberg, Mykyta Yevstifeyev, Alec Rowell, Jaroslav Dunajsky, Wade Hilmo, Anthony Bryan, and Barry Leiba for their assistance.
一些人提供了大量关于本文件早期版本的建设性反馈，这些反馈有助于形成本文件的发展；他们的许多建议已被采纳，他们的贡献得到了感谢。这里有太多要提及的内容，但本文件的作者要特别感谢Alexey Melnikov、Alfred Hoenes、John Klesins、Joe Touch、Paul Ford Hutchinson、Daniel Stenberg、Mykyta Yevstifeyev、Alec Rowell、Jaroslav Dunajsky、Wade Hilmo、Anthony Bryan和Barry Leiba的帮助。
Authors' Addresses
作者地址
Paul Hethmon Hethmon Brothers 2305 Chukar Road Knoxville, TN 37923 USA
保罗·赫特蒙·赫特蒙兄弟美国田纳西州诺克斯维尔丘卡尔路2305号，邮编：37923
EMail: phethmon@hethmon.com
EMail: phethmon@hethmon.com
Robert McMurray Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
罗伯特·麦克默里微软公司美国华盛顿州雷德蒙微软大道一号，邮编：98052
EMail: robmcm@microsoft.com
EMail: robmcm@microsoft.com