Network Working Group K. Moore
Request for Comments: 3205 University of Tennessee
BCP: 56 February 2002
Category: Best Current Practice
Network Working Group K. Moore
Request for Comments: 3205 University of Tennessee
BCP: 56 February 2002
Category: Best Current Practice
On the use of HTTP as a Substrate
HTTP作为底层的使用
Status of this Memo
本备忘录的状况
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
Recently there has been widespread interest in using Hypertext Transfer Protocol (HTTP) as a substrate for other applications-level protocols. This document recommends technical particulars of such use, including use of default ports, URL schemes, and HTTP security mechanisms.
最近，使用超文本传输协议（HTTP）作为其他应用程序级协议的基础引起了广泛的兴趣。本文档推荐了此类使用的技术细节，包括默认端口、URL方案和HTTP安全机制的使用。
Recently there has been widespread interest in using Hypertext Transfer Protocol (HTTP) [1] as a substrate for other applications-level protocols. Various reasons cited for this interest have included:
最近，使用超文本传输协议（HTTP）[1]作为其他应用程序级协议的基础引起了广泛的兴趣。出于这种兴趣，列举的各种原因包括：
o familiarity and mindshare,
o 熟悉和分享，
o compatibility with widely deployed browsers,
o 与广泛部署的浏览器兼容，
o ability to reuse existing servers and client libraries,
o 能够重用现有服务器和客户端库，
o ease of prototyping servers using CGI scripts and similar extension mechanisms,
o 使用CGI脚本和类似扩展机制简化服务器原型，
o ability to use existing security mechanisms such as HTTP digest authentication [2] and SSL or TLS [3],
o 能够使用现有的安全机制，如HTTP摘要身份验证[2]和SSL或TLS[3]，
o the ability of HTTP to traverse firewalls, and
o HTTP穿越防火墙的能力，以及
o cases where a server often needs to support HTTP anyway.
o 服务器通常需要支持HTTP的情况。
The Internet community has a long tradition of protocol reuse, dating back to the use of Telnet [4] as a substrate for FTP [5] and SMTP [6]. However, the recent interest in layering new protocols over HTTP has raised a number of questions when such use is appropriate, and the proper way to use HTTP in contexts where it is appropriate. Specifically, for a given application that is layered on top of HTTP:
互联网社区在协议重用方面有着悠久的传统，可以追溯到使用Telnet[4]作为FTP[5]和SMTP[6]的基础。然而，最近对在HTTP上分层新协议的兴趣提出了许多问题，例如何时使用HTTP是合适的，以及在合适的上下文中使用HTTP的正确方式。具体而言，对于在HTTP之上分层的给定应用程序：
o Should the application use a different port than the HTTP default of 80?
o 应用程序是否应该使用与HTTP默认端口80不同的端口？
o Should the application use traditional HTTP methods (GET, POST, etc.) or should it define new methods?
o 应用程序应该使用传统的HTTP方法（GET、POST等），还是应该定义新方法？
o Should the application use http: URLs or define its own prefix?
o 应用程序应该使用http:url还是定义自己的前缀？
o Should the application define its own MIME-types, or use something that already exists (like registering a new type of MIME-directory structure)?
o 应用程序应该定义自己的MIME类型，还是使用已经存在的类型（例如注册新类型的MIME目录结构）？
This memo recommends certain design decisions in answer to these questions.
本备忘录针对这些问题建议了某些设计决策。
This memo is intended as advice and recommendation for protocol designers, working groups, implementors, and IESG, rather than as a strict set of rules which must be adhered to in all cases. Accordingly, the capitalized key words defined in RFC 2119, which are intended to indicate conformance to a specification, are not used in this memo.
本备忘录旨在为协议设计者、工作组、实施者和IESG提供建议和建议，而不是在任何情况下都必须遵守的一套严格规则。因此，本备忘录中不使用RFC 2119中定义的大写关键字，这些关键字旨在表示符合规范。
Despite the advantages listed above, it's worth asking the question as to whether HTTP should be used at all, or whether the entire HTTP protocol should be used.
尽管有上面列出的优点，但值得一提的问题是，到底是应该使用HTTP，还是应该使用整个HTTP协议。
HTTP started out as a simple protocol, but quickly became much more complex due to the addition of several features unanticipated by its original design. These features include persistent connections, byte ranges, content negotiation, and cache support. All of these are useful for traditional web applications but may not be useful for the layered application. The need to support (or circumvent) these features can add additional complexity to the design and implementation of a protocol layered on top of HTTP. Even when HTTP can be "profiled" to minimize implementation overhead, the effort of specifying such a profile might be more than the effort of specifying a purpose-built protocol which is better suited to the task at hand.
HTTP一开始只是一个简单的协议，但很快就变得更加复杂，因为它添加了一些其原始设计所没有想到的特性。这些特性包括持久连接、字节范围、内容协商和缓存支持。所有这些对于传统的web应用程序都很有用，但对于分层应用程序可能并不有用。支持（或规避）这些特性的需要会增加HTTP之上分层协议的设计和实现的复杂性。即使可以对HTTP进行“分析”以最小化实现开销，指定此类分析的工作也可能比指定更适合手头任务的专门构建协议的工作要多。
Even if existing HTTP client and server code can often be re-used, the additional complexity of layering something over HTTP vs. using a purpose-built protocol can increase the number of interoperability problems.
即使现有的HTTP客户机和服务器代码经常可以重复使用，与使用专门构建的协议相比，在HTTP上分层的额外复杂性也会增加互操作性问题的数量。
Further, although HTTP can be used as the transport for a "remote procedure call" paradigm, HTTP's protocol overhead, along with the connection setup overhead of TCP, can make HTTP a poor choice. A protocol based on UDP, or with both UDP and TCP variants, should be considered if the payloads are very likely to be small (less than a few hundred bytes) for the foreseeable future. This is especially true if the protocol might be heavily used, or if it might be used over slow or expensive links.
此外，尽管HTTP可以用作“远程过程调用”范例的传输，但HTTP的协议开销以及TCP的连接设置开销可能使HTTP成为一个糟糕的选择。如果有效负载在可预见的将来很可能很小（小于几百字节），则应考虑基于UDP的协议，或同时使用UDP和TCP变体的协议。如果协议可能被大量使用，或者可能在慢速或昂贵的链路上使用，则尤其如此。
On the other hand, the connection setup overhead can become negligible if the layered protocol can utilize HTTP/1.1's persistent connections, and if the same client and server are likely to perform several transactions during the time the HTTP connection is open.
另一方面，如果分层协议可以利用HTTP/1.1的持久连接，并且如果同一客户机和服务器可能在HTTP连接打开期间执行多个事务，则连接设置开销可以忽略不计。
Although HTTP appears at first glance to be one of the few "mature" Internet protocols that can provide good security, there are many applications for which neither HTTP's digest authentication nor TLS are sufficient by themselves.
虽然HTTP乍一看似乎是为数不多的能够提供良好安全性的“成熟”Internet协议之一，但许多应用程序本身既不具备HTTP摘要身份验证，也不具备TLS。
Digest authentication requires a secret (e.g., a password) to be shared between client and server. This further requires that each client know the secret to be used with each server, but it does not provide any means of securely transmitting such secrets between the parties. Shared secrets can work fine for small groups where everyone is physically co-located; they don't work as well for large or dispersed communities of users. Further, if the server is compromised a large number of secrets may be exposed, which is especially dangerous if the same secret (or password) is used for several applications. (Similar concerns exist with TLS based clients or servers - if a private key is compromised then the attacker can impersonate the party whose key it has.)
摘要身份验证要求在客户端和服务器之间共享一个秘密（例如密码）。这进一步要求每个客户机知道要与每个服务器一起使用的秘密，但它不提供任何在双方之间安全传输此类秘密的方法。共享秘密对于每个人都在同一地点的小团体来说效果很好；对于大型或分散的用户社区，它们的工作效果并不理想。此外，如果服务器被泄露，可能会暴露大量机密，如果在多个应用程序中使用相同的机密（或密码），这尤其危险。（基于TLS的客户端或服务器也存在类似的问题-如果私钥被泄露，则攻击者可以模拟拥有其密钥的一方。）
TLS and its predecessor SSL were originally designed to authenticate web servers to clients, so that a user could be assured (for example) that his credit card number was not being sent to an imposter. However, many applications need to authenticate clients to servers, or to provide mutual authentication of client and server. TLS does
TLS及其前身SSL最初设计用于向客户端验证web服务器，这样用户就可以（例如）确信他的信用卡号没有被发送给冒名顶替者。然而，许多应用程序需要对客户端到服务器进行身份验证，或者提供客户端和服务器的相互身份验证。TLS有
have a capability to provide authentication in each direction, but such authentication may or may not be suitable for a particular application.
具有在每个方向提供身份验证的能力，但此类身份验证可能适用于或可能不适用于特定应用。
Web browsers which support TLS or SSL are typically shipped with the public keys of several certificate authorities (CAs) "wired in" so that they can verify the identity of any server whose public key was signed by one of those CAs. For this to work well, every secure web server's public key has to be signed by one of the CAs whose keys are wired into popular browsers. This deployment model works when there are a (relatively) small number of servers whose identities can be verified, and their public keys signed, by the small number of CAs whose keys are included in a small number of different browsers.
支持TLS或SSL的Web浏览器通常附带多个证书颁发机构（CA）“有线连接”的公钥，以便它们可以验证其公钥由其中一个CA签名的任何服务器的身份。为了使其正常工作，每个安全web服务器的公钥都必须由一个CA签名，CA的密钥连接到流行的浏览器中。当（相对）少量服务器的身份可以通过少量CA进行验证，并且它们的公钥可以由少量CA签名时，此部署模型就可以工作，这些CA的密钥包含在少量不同的浏览器中。
This scheme does not work as well to authenticate millions of potential clients to servers. It would take a much larger number of CAs to do the job, each of which would need to be widely trusted by servers. Those CAs would also have a more difficult time verifying the identities of (large numbers of) ordinary users than they do in verifying the identities of (a smaller number of) commercial and other enterprises that need to run secure web servers.
此方案不适用于将数百万潜在客户机验证到服务器。完成这项工作需要大量CA，每个CA都需要得到服务器的广泛信任。与需要运行安全web服务器的商业和其他企业（数量较少）的身份验证相比，这些CA在验证（大量）普通用户的身份方面的难度更大。
Also, in a situation where there were a large number of clients authenticating with TLS, it seems unlikely that there would be a set of CAs whose keys were trusted by every server. A client that potentially needed to authenticate to multiple servers would therefore need to be configured as to which key to use with which server when attempting to establish a secure connection to the server.
此外，在有大量客户机使用TLS进行身份验证的情况下，似乎不太可能有一组CA，其密钥受每台服务器的信任。因此，可能需要向多个服务器进行身份验证的客户端需要配置为在尝试与服务器建立安全连接时使用哪个服务器的密钥。
For the reasons stated above, client authentication is rarely used with TLS. A common technique is to use TLS to authenticate the server to the client and to establish a private channel, and for the client to authenticate to the server using some other means - for example, a username and password using HTTP basic or digest authentication.
出于上述原因，TLS很少使用客户端身份验证。一种常见的技术是使用TLS向客户机验证服务器并建立专用通道，以及让客户机使用其他方式向服务器进行验证—例如，使用HTTP basic或digest身份验证的用户名和密码。
For any application that requires privacy, the 40-bit ciphersuites provided by some SSL implementations (to conform to outdated US export regulations or to regulations on the use or export of cryptography in other countries) are unsuitable. Even 56-bit DES encryption, which is required of conforming TLS implementations, has been broken in a matter of days with a modest investment in resources. So if TLS is chosen it may be necessary to discourage use of small key lengths, or of weak ciphersuites, in order to provide adequate privacy assurance. If TLS is used to provide privacy for passwords sent by clients then it is especially important to support longer keys.
对于任何需要隐私的应用程序，某些SSL实现提供的40位密码套件（以符合过时的美国出口法规或其他国家使用或出口密码的法规）是不合适的。即使是符合TLS实施要求的56位DES加密，也在几天内被打破，只需投入少量资源。因此，如果选择TLS，可能有必要阻止使用小密钥长度或弱密码套件，以提供充分的隐私保证。如果TLS用于为客户端发送的密码提供隐私，那么支持更长的密钥尤其重要。
None of the above should be taken to mean that either digest authentication or TLS are generally inferior to other authentication systems, or that they are unsuitable for use in other applications besides HTTP. Many of the limitations of TLS and digest authentication also apply to other authentication and privacy systems. The point here is that neither TLS nor digest authentication is a "magic pixie dust" solution to authentication or privacy. In every case, an application's designers must carefully determine the application's users' requirements for authentication and privacy before choosing an authentication or privacy mechanism.
上述任何一项都不应被视为意味着摘要认证或TLS通常不如其他认证系统，或者它们不适合在HTTP以外的其他应用程序中使用。TLS和摘要认证的许多限制也适用于其他认证和隐私系统。这里的要点是，TLS和digest身份验证都不是身份验证或隐私的“魔法精灵灰尘”解决方案。在任何情况下，应用程序的设计者都必须在选择身份验证或隐私机制之前仔细确定应用程序用户对身份验证和隐私的要求。
Note also that TLS can be used with other TCP-based protocols, and there are SASL [7] mechanisms similar to HTTP's digest authentication. So it is not necessary to use HTTP in order to benefit from either TLS or digest-like authentication. However, HTTP APIs may already support TLS and/or digest.
还请注意，TLS可以与其他基于TCP的协议一起使用，并且存在类似于HTTP摘要身份验证的SASL[7]机制。因此，为了从TLS或类似摘要的身份验证中获益，没有必要使用HTTP。但是，HTTP API可能已经支持TLS和/或摘要。
One oft-cited reason for the use of HTTP is its ability to pass through proxies, firewalls, or network address translators (NATs). One unfortunate consequence of firewalls and NATs is that they make it harder to deploy new Internet applications, by requiring explicit permission (or even a software upgrade of the firewall or NAT) to accommodate each new protocol. The existence of firewalls and NATs creates a strong incentive for protocol designers to layer new applications on top of existing protocols, including HTTP.
使用HTTP的一个经常被引用的原因是它能够通过代理、防火墙或网络地址转换器（NAT）。防火墙和NAT的一个不幸后果是，它们需要明确的许可（甚至是防火墙或NAT的软件升级）来适应每一个新协议，从而使部署新的Internet应用程序变得更加困难。防火墙和NAT的存在极大地激励了协议设计者在现有协议（包括HTTP）的基础上分层新的应用程序。
However, if a site's firewall prevents the use of unknown protocols, this is presumably a conscious policy decision on the part of the firewall administrator. While it is arguable that such policies are of limited value in enhancing security, this is beside the point - well-known port numbers are quite useful for a variety of purposes, and the overloading of port numbers erodes this utility. Attempting to circumvent a site's security policy is not an acceptable justification for doing so.
但是，如果站点的防火墙阻止使用未知协议，这可能是防火墙管理员有意识的策略决定。虽然有争议的是，此类策略在增强安全性方面的价值有限，但这与问题无关——众所周知的端口号对于各种用途都非常有用，并且端口号过载会侵蚀这一效用。试图规避站点的安全策略是不可接受的。
It would be useful to establish guidelines for "firewall-friendly" protocols, to make it easier for existing firewalls to be compatible with new protocols.
为“防火墙友好”协议制定指导方针将是有益的，以使现有防火墙更容易与新协议兼容。
o When considering payload size and traffic patterns, is HTTP an appropriate transport for the anticipated use of this protocol?
o 在考虑有效负载大小和流量模式时，HTTP是否适合预期使用该协议？
(In other words: will the payload size be worth the overhead associated with TCP and HTTP? Or will the application be able to make use of HTTP persistent connections to amortize the cost of that overhead over several requests?)
（换句话说：有效负载大小是否值得与TCP和HTTP相关的开销？或者应用程序是否能够利用HTTP持久连接将该开销的成本分摊到多个请求上？）
o Is this new protocol usable by existing web browsers without modification?
o 这个新协议是否可以被现有的web浏览器使用而无需修改？
(For example: Is the request transmitted as if it were a filled-in HTML form? Is the response which is returned viewable from a web browser, say as HTML?)
（例如：请求是否像已填写的HTML表单一样传输？返回的响应是否可以从web浏览器（例如HTML）中查看？）
o Are the existing HTTP security mechanisms appropriate for the new application?
o 现有的HTTP安全机制是否适合新的应用程序？
o Are HTTP status codes and the HTTP status code paradigm suitable for this application? (see section 8)
o HTTP状态代码和HTTP状态代码范例是否适合此应用程序？（见第8节）
o Does the server for this application need to support HTTP anyway?
o 此应用程序的服务器是否仍需要支持HTTP？
IANA has reserved TCP port number 80 for use by HTTP. It would not be appropriate for a substantially new service, even one which uses HTTP as a substrate, to usurp port 80 from its traditional use. A new use of HTTP might be considered a "substantially new service", thus requiring a new port, if any of the following are true:
IANA已保留TCP端口号80供HTTP使用。对于一个实质上全新的服务（即使是使用HTTP作为底层的服务）来说，将端口80从其传统用途中篡夺是不合适的。HTTP的新用途可能被视为“实质上的新服务”，因此需要一个新端口，如果以下任何一项为真：
o The "new service" and traditional HTTP service are likely to reference different sets of data, even when they both operate on the same host.
o “新服务”和传统HTTP服务可能引用不同的数据集，即使它们都在同一台主机上运行。
o There is a good reason for the "new service" to be implemented by a separate server process, or separate code, than traditional HTTP service on the same host, at least on some platforms.
o 与同一主机上的传统HTTP服务相比，至少在某些平台上，“新服务”由单独的服务器进程或单独的代码实现是有充分理由的。
o There is a good reason to want to easily distinguish the traffic of the "new service" from traditional HTTP, e.g., for the purposes of firewall access control or traffic analysis.
o 有一个很好的理由希望轻松区分“新服务”的流量与传统HTTP的流量，例如，出于防火墙访问控制或流量分析的目的。
o If none of the above are true, it is arguable that the new use of HTTP is an "extension" to traditional HTTP, rather than a "new service". Extensions to HTTP which share data with traditional HTTP services should probably define new HTTP methods to describe those extensions, rather than using separate ports. If separate ports are used, there is no way for a client to know whether they are separate services or different ways of accessing the same underlying service.
o 如果以上都不是真的，那么HTTP的新用途是对传统HTTP的“扩展”，而不是“新服务”，这是有争议的。与传统HTTP服务共享数据的HTTP扩展可能应该定义新的HTTP方法来描述这些扩展，而不是使用单独的端口。如果使用单独的端口，客户端无法知道它们是单独的服务还是访问同一基础服务的不同方式。
A number of different URL schemes are in widespread use and many more are in the process of being standardized. In practice, the URL scheme not only serves as a "tag" to govern the interpretation of the remaining portion of the URL, it also provides coarse identification of the kind of resource or service which is being accessed. For example, web browsers typically provide a different response when a user mouse-clicks on an "http" URL, than when the user clicks on a "mailto" URL.
许多不同的URL方案正在广泛使用，更多的方案正在标准化。在实践中，URL方案不仅充当“标签”来管理URL其余部分的解释，还提供正在访问的资源或服务类型的粗略标识。例如，当用户鼠标单击“http”URL时，web浏览器通常会提供与用户单击“mailto”URL时不同的响应。
Some criteria that might be used in making this determination are:
在作出这一决定时可能使用的一些标准是：
o Whether this URL scheme is likely to become widely used, versus used only in limited communities or by private agreement.
o 此URL方案是否可能被广泛使用，而不是仅在有限的社区或通过私人协议使用。
o Whether a new "default port" is needed. If reuse of port 80 is not appropriate (see above), a new "default port" is needed. A new default port in turn requires that a new URL scheme be registered if that URL scheme is expected to be widely used. Explicit port numbers in URLs are regarded as an "escape hatch", not something for use in ordinary circumstances.
o 是否需要新的“默认端口”。如果重新使用端口80不合适（见上文），则需要一个新的“默认端口”。一个新的默认端口反过来要求注册一个新的URL方案，如果该URL方案被广泛使用的话。URL中的显式端口号被视为“转义图案填充”，而不是在普通情况下使用的。
o Whether use of the new service is likely to require a substantially different setup or protocol interaction with the server, than ordinary HTTP service. This could include the need to request a different type of service from the network, or to reserve bandwidth, or to present different TLS authentication credentials to the server, or different kind of server provisioning, or any number of other needs.
o 与普通HTTP服务相比，新服务的使用是否可能需要与服务器进行实质性不同的设置或协议交互。这可能包括需要从网络请求不同类型的服务，或保留带宽，或向服务器提供不同的TLS身份验证凭据，或不同类型的服务器配置，或任何数量的其他需要。
o Whether user interfaces (such as web browsers) are likely to be able to exploit the difference in the URL prefix to produce a significant improvement in usability.
o 用户界面（如web浏览器）是否能够利用URL前缀的差异来显著提高可用性。
According to the rules in [8] the "http:" URI is part of the "IETF Tree" for URL scheme names, and IETF is the maintainer of the "IETF Tree". Since IESG is the decision-making body for IETF, IESG has the authority to determine whether a resource accessed by a protocol that is layered on top of HTTP, should use http: or some other URL prefix.
根据[8]中的规则，“http:”URI是URL方案名称“IETF树”的一部分，IETF是“IETF树”的维护者。由于IESG是IETF的决策机构，IESG有权确定由HTTP之上的协议访问的资源是否应使用HTTP:或其他URL前缀。
Note that the convention of appending an "s" to the URL scheme to mean "use TLS or SSL" (as in "http:" vs "https:") is nonstandard and of limited value. For most applications, a single "use TLS or SSL" bit is not sufficient to adequately convey the information that a client needs to authenticate itself to a server, even if it has the proper credentials. For instance, in order to ensure that adequate security is provided with TLS an application may need to be
请注意，将“s”添加到URL方案以表示“使用TLS或SSL”（如“http:”vs“https:”）的约定是非标准的，并且价值有限。对于大多数应用程序，一个“使用TLS或SSL”位不足以将客户机进行自我验证所需的信息充分传递给服务器，即使它具有正确的凭据。例如，为了确保TLS具有足够的安全性，可能需要安装一个应用程序
configured with a list of acceptable ciphersuites, or with the client certificate to be used to authenticate to a particular server. When it is necessary to specify authentication or other connection setup information in a URL these should be communicated in URL parameters, rather than in the URL prefix.
配置了可接受的密码套件列表，或配置了用于向特定服务器进行身份验证的客户端证书。当需要在URL中指定身份验证或其他连接设置信息时，这些信息应该在URL参数中传递，而不是在URL前缀中传递。
Since HTTP uses the MIME media type system [9] to label its payload, many applications which layer on HTTP will need to define, or select, MIME media types for use by that application. Especially when using a multipart structure, the choice of media types requires careful consideration. In particular:
由于HTTP使用MIME媒体类型系统[9]来标记其有效负载，因此HTTP上的许多应用程序需要定义或选择MIME媒体类型以供该应用程序使用。特别是在使用多部分结构时，媒体类型的选择需要仔细考虑。特别地：
o Should some existing framework be used, such as text/directory [10], or XML [11,12], or should the new content-types be built from scratch? Just as with HTTP, it's useful if code can be reused, but protocol designers should not be over-eager to incorporate a general but complex framework into a new protocol. Experience with ASN.1, for example, suggests that the advantage of using a general framework may not be worth the cost.
o 应该使用一些现有的框架，比如text/directory[10]或XML[11,12]，还是应该从头构建新的内容类型？与HTTP一样，如果代码可以重用，它也很有用，但是协议设计者不应该急于将一个通用但复杂的框架合并到一个新协议中。例如，ASN.1的经验表明，使用通用框架的优势可能不值得付出代价。
o Should MIME multipart or message types be allowed? This can be an advantage if it is desirable to incorporate (for example) the multipart/alternative construct or the MIME security framework. On the other hand, these constructs were designed specifically for use in store-and-forward electronic mail systems, and other mechanisms may be more appropriate for the application being considered.
o 应该允许MIME多部分或消息类型吗？如果希望合并（例如）多部分/替代结构或MIME安全框架，这可能是一个优势。另一方面，这些构造是专门为存储转发电子邮件系统设计的，其他机制可能更适合所考虑的应用程序。
The point here is that a decision to use MIME content-type names to describe protocol payloads (which is generally desirable if the same payloads may appear in other applications) does not imply that the application must accept arbitrary MIME content-types, including MIME multipart or security mechanisms. Nor does it imply that the application must use MIME syntax or that it must recognize or even tolerate existing MIME header fields.
这里的要点是，决定使用MIME内容类型名称来描述协议有效负载（如果相同的有效负载可能出现在其他应用程序中，这通常是可取的）并不意味着应用程序必须接受任意MIME内容类型，包括MIME多部分或安全机制。这也不意味着应用程序必须使用MIME语法，或者必须识别甚至容忍现有的MIME头字段。
o If the same payload is likely to be sent over electronic mail, the differences between HTTP encoding of the payload and email encoding of the payload should be minimized. Ideally, there should be no differences in the "canonical form" used in the two environments. Text/* media types can be problematic in this regard because MIME email requires CRLF for line endings of text/* body parts, where HTTP traditionally uses LF only.
o 如果可能通过电子邮件发送相同的有效负载，则应尽量减少有效负载的HTTP编码和有效负载的电子邮件编码之间的差异。理想情况下，两种环境中使用的“规范形式”应该没有区别。Text/*媒体类型在这方面可能会有问题，因为MIME电子邮件需要CRLF作为Text/*正文部分的行尾，而HTTP传统上仅使用LF。
o A MIME content-type label describes the nature of the object being labeled. It does not describe, and should not be used to describe, the semantics which should be applied when the object is received. For instance, the transmission of an object with a particular content-type using HTTP POST, should not be taken as a request for some operation based solely on the type. The request should be separate from the content-type label and it should be explicit.
o MIME内容类型标签描述被标记对象的性质。它不描述，也不应用于描述接收对象时应应用的语义。例如，使用HTTP POST传输具有特定内容类型的对象不应被视为仅基于该类型的某些操作的请求。请求应该与内容类型标签分开，并且应该是明确的。
When it is necessary for a protocol layered on HTTP to allow different operations on the same type of object, this can be communicated in a number of different ways: HTTP methods, HTTP request-URI, HTTP request headers, the MIME Content-Disposition header field, or as part of the payload.
当需要在HTTP上分层的协议允许对同一类型的对象执行不同的操作时，可以通过多种不同的方式进行通信：HTTP方法、HTTP请求URI、HTTP请求头、MIME内容处置头字段或作为有效负载的一部分。
It has been suggested that a new service layered on top of HTTP should define one or more new HTTP methods, rather than allocating a new port. The use of new methods may be appropriate, but is not sufficient in all cases. The definition of one or more new methods for use in a new protocol, does not by itself alleviate the need for use of a new port, or a new URL type.
有人建议，在HTTP之上分层的新服务应该定义一个或多个新的HTTP方法，而不是分配一个新端口。使用新方法可能是适当的，但并非在所有情况下都是充分的。在新协议中使用的一个或多个新方法的定义本身并不减轻使用新端口或新URL类型的需要。
As mentioned earlier, one of the primary reasons for the use of HTTP as a substrate for new protocols, is to allow reuse of existing HTTP client, server, or proxy code. However, HTTP was not designed for such layering. Existing HTTP client and code may have "http" assumptions wired into them. For instance, client libraries and proxies may expect "http:" URLs, and clients and servers may send (and expect) "HTTP/1.1", in requests and responses, as opposed to the name of the layered protocol and its version number.
如前所述，使用HTTP作为新协议的基础的主要原因之一是允许重用现有HTTP客户端、服务器或代理代码。然而，HTTP并不是为这种分层而设计的。现有的HTTP客户机和代码中可能包含“HTTP”假设。例如，客户端库和代理可能期望在请求和响应中使用“http:”URL，客户端和服务器可能发送（并期望）“http/1.1”，而不是使用分层协议的名称及其版本号。
Existing client libraries may not understand new URL types. In order to get a new HTTP-layered application client to work with an existing client library, it may be necessary for the application to convert its URLs to an "http equivalent" form. For instance, if service "xyz" is layered on top of HTTP using port ###, the xyz client may need, when invoking an HTTP client library, to translate its URLs from "xyz://host/something" format to "http://host:###/something" for the purpose of calling that library. This should be done ONLY when calling the HTTP client library - such URLs should not be used in other parts of the protocol, nor should they be exposed to users.
现有客户端库可能无法理解新的URL类型。为了让新的HTTP分层应用程序客户端与现有的客户端库一起工作，应用程序可能需要将其URL转换为“HTTP等效”形式。例如，如果使用端口#####将服务“xyz”分层到HTTP之上，则xyz客户端在调用HTTP客户端库时可能需要将其URL从xyz://host/something“格式化为”http://host:###/something“为了给图书馆打电话。只有在调用HTTP客户机库时才应该这样做——这样的URL不应该在协议的其他部分中使用，也不应该向用户公开。
Note that when a client is sending requests directly to an origin server, the URL prefix ("http:") is not normally sent. So translating xyz: URLs to http: URLs when calling the client library should not actually cause http: URLs to be sent over the wire. But when the same client is sending requests to a proxy server, the client will normally send the entire URL (including the http: prefix) in those requests. The proxy will remove the http: prefix when the request is communicated to the origin server.
请注意，当客户端直接向源服务器发送请求时，通常不会发送URL前缀（“http:”）。因此，在调用客户机库时，将xyz:url转换为http:url实际上不应导致通过网络发送http:url。但是，当同一个客户端向代理服务器发送请求时，客户端通常会在这些请求中发送整个URL（包括http:前缀）。当请求被传送到源服务器时，代理将删除http:前缀。
Existing HTTP client libraries and servers will transmit "HTTP/1.1" (or a different version) in requests and responses. To facilitate reuse of such libraries and servers by a new protocol, such a protocol may therefore need to transmit and accept "HTTP/1.1" rather than its own protocol name and version number. Designers of protocols which are layered on top of HTTP should explicitly choose whether or not to accept "HTTP/1.1" in protocol exchanges.
现有HTTP客户端库和服务器将在请求和响应中传输“HTTP/1.1”（或不同版本）。为了便于通过新协议重用此类库和服务器，此类协议可能因此需要传输和接受“HTTP/1.1”，而不是其自身的协议名称和版本号。在HTTP之上分层的协议的设计者应该明确选择是否在协议交换中接受“HTTP/1.1”。
For certain applications it may be necessary to require or limit use of certain HTTP features, for example, to defeat caching of responses by proxies. Each protocol layered on HTTP must therefore specify the specific way that HTTP will be used, and in particular, how the client and server should interact with HTTP proxies.
对于某些应用程序，可能需要要求或限制使用某些HTTP功能，例如，阻止代理缓存响应。因此，在HTTP上分层的每个协议必须指定HTTP的具体使用方式，特别是客户端和服务器应如何与HTTP代理交互。
HTTP's three-digit status codes were designed for use with traditional HTTP applications (e.g., document retrieval, forms-based queries), and are unlikely to be suitable to communicate the specifics of errors encountered in dissimilar applications. Even when it seems like there is a close match between HTTP status codes and the codes needed by the application, experience with reuse of other protocols indicates that subtle variations in usage are likely; and that this is likely to degrade interoperability of both the original protocol (in this case HTTP) and any layered applications.
HTTP的三位数状态代码是为与传统HTTP应用程序（例如，文档检索、基于表单的查询）一起使用而设计的，不太可能适合传达不同应用程序中遇到的错误的细节。即使在HTTP状态代码和应用程序所需的代码之间似乎存在着密切的匹配，但重用其他协议的经验表明，可能会出现使用上的细微变化；这可能会降低原始协议（在本例中为HTTP）和任何分层应用程序的互操作性。
HTTP status codes therefore should not be used to indicate subtle errors of layered applications. At most, the "generic" HTTP codes 200 (for complete success) and 500 (for complete failure) should be used to indicate errors resulting from the content of the request message-body. Under certain circumstances, additional detail about the nature of the error can then be included in the response message-body. Other status codes than 200 or 500 should only appear if the error was detected by the HTTP server or by an intermediary.
因此，HTTP状态代码不应用于指示分层应用程序的细微错误。最多应使用“通用”HTTP代码200（表示完全成功）和500（表示完全失败）来指示由请求消息正文的内容导致的错误。在某些情况下，有关错误性质的其他详细信息可以包含在响应消息正文中。只有当HTTP服务器或中介检测到错误时，才会出现200或500以外的其他状态代码。
A layered application should not define new HTTP status codes. The set of available status codes is small, conflicts in code assignment between different layered applications are likely, and they may be needed by future versions of, or extensions to, mainstream HTTP.
分层应用程序不应定义新的HTTP状态代码。可用的状态代码集很小，不同分层应用程序之间的代码分配可能存在冲突，主流HTTP的未来版本或扩展可能需要这些代码。
Use of HTTP's error codes is problematic when the layered application does not share same notion of success or failure as HTTP. The problem exists when the client does not connect directly to the origin server, but via one or more HTTP caches or proxies. (Since the ability of HTTP to communicate through intermediaries is often the primary motivation for reusing HTTP, the ability of the application to operate in the presence of such intermediaries is considered very important.) Such caches and proxies will interpret HTTP's error codes and may take additional action based on those codes. For instance, on receipt of a 200 error code from an origin server (and under other appropriate conditions) a proxy may cache the response and re-issue it in response to a similar request. Or a proxy may modify the result of a request which returns a 500 error code in order to add a "helpful" error message. Other response codes may produce other behaviors.
当分层应用程序与HTTP没有相同的成功或失败概念时，HTTP错误代码的使用是有问题的。当客户端不直接连接到源服务器，而是通过一个或多个HTTP缓存或代理连接时，就会出现问题。（由于HTTP通过中介进行通信的能力通常是重用HTTP的主要动机，因此应用程序在此类中介存在的情况下运行的能力被认为是非常重要的。）此类缓存和代理将解释HTTP的错误代码，并可能根据这些代码采取其他操作。例如，在从源服务器（以及在其他适当条件下）接收到200个错误代码后，代理可以缓存响应，并在响应类似请求时重新发出响应。或者，代理可以修改返回500错误代码的请求的结果，以便添加“有用”错误消息。其他响应代码可能会产生其他行为。
A few guidelines are therefore in order:
因此，应遵循以下几条准则：
o A layered application should use appropriate HTTP error codes to report errors resulting from information in the HTTP request-line and header fields associated with the request. This request information is part of the HTTP protocol and errors which are associated with that information should therefore be reported using HTTP protocol mechanisms.
o 分层应用程序应该使用适当的HTTP错误代码来报告由HTTP请求行和与请求相关联的头字段中的信息导致的错误。此请求信息是HTTP协议的一部分，因此应使用HTTP协议机制报告与该信息相关的错误。
o A layered application for which all errors resulting from the message-body can be classified as either "complete success" or "complete failure" may use 200 and 500 for those conditions, respectively. However, the specification for such an application must define the mechanism which ensures that its successful (200) responses are not cached by intermediaries, or demonstrate that such caching will do no harm; and it must be able to operate even if the message-body of an error (500) response is not transmitted back to the client intact.
o 对于由消息体产生的所有错误可被分类为“完全成功”或“完全失败”的分层应用程序，在这些条件下可分别使用200和500。然而，此类应用程序的规范必须定义确保其成功（200）响应不会被中介缓存的机制，或证明此类缓存不会造成损害；即使错误（500）响应的消息体没有完整地传输回客户端，它也必须能够运行。
o A layered application may return a 200 response code for both successfully processed requests and errors (or other exceptional conditions) resulting from the request message-body (but not from the request headers). Such an application must return its error code as part of the response message body, and the specification for that application protocol must define the mechanism by which the application ensures that its responses are not cached by intermediaries. In this case a response other than 200 should be used only to indicate errors with, or the status of, the HTTP protocol layer (including the request headers), or to indicate the inability of the HTTP server to communicate with the application server.
o 分层应用程序可能会为成功处理的请求和由请求消息体（但不是请求头）导致的错误（或其他异常情况）返回200响应代码。这样的应用程序必须将其错误代码作为响应消息体的一部分返回，并且该应用程序协议的规范必须定义应用程序确保其响应不被中介缓存的机制。在这种情况下，200以外的响应应仅用于指示HTTP协议层（包括请求头）的错误或状态，或指示HTTP服务器无法与应用服务器通信。
o A layered application which cannot operate in the presence of intermediaries or proxies that cache and/or alter error responses, should not use HTTP as a substrate.
o 无法在缓存和/或更改错误响应的中介或代理存在的情况下运行的分层应用程序不应使用HTTP作为底层。
1. All protocols should provide adequate security. The security needs of a particular application will vary widely depending on the application and its anticipated use environment. Merely using HTTP and/or TLS as a substrate for a protocol does not automatically provide adequate security for all environments, nor does it relieve the protocol developers of the need to analyze security considerations for their particular application.
1. 所有协议都应提供足够的安全性。根据应用程序及其预期使用环境的不同，特定应用程序的安全需求会有很大差异。仅仅使用HTTP和/或TLS作为协议的基础并不能自动为所有环境提供足够的安全性，也不能免除协议开发人员分析其特定应用程序的安全考虑因素的需要。
2. New protocols - including but not limited to those using HTTP - should not attempt to circumvent users' firewall policies, particularly by masquerading as existing protocols. "Substantially new services" should not reuse existing ports.
2. 新协议——包括但不限于使用HTTP的协议——不应试图绕过用户的防火墙策略，特别是伪装成现有协议。“实质上是新的服务”不应重用现有端口。
3. In general, new protocols or services should not reuse http: or other URL schemes.
3. 一般来说，新的协议或服务不应该重用http:或其他URL方案。
4. Each new protocol specification that uses HTTP as a substrate should describe the specific way that HTTP is to be used by that protocol, including how the client and server interact with proxies.
4. 每个使用HTTP作为基础的新协议规范都应该描述该协议使用HTTP的具体方式，包括客户端和服务器如何与代理交互。
5. New services should follow the guidelines in section 8 regarding use of HTTP status codes.
5. 新服务应遵循第8节中有关HTTP状态代码使用的指南。
Much of this document is about security. Section 2.3 discusses whether HTTP security is adequate for the needs of a particular application, section 2.4 discusses interactions between new HTTP-based protocols and firewalls, section 3 discusses use of separate ports so that firewalls are not circumvented, and section 4 discusses the inadequacy of the "s" suffix of a URL prefix for specifying security levels.
本文档的大部分内容都是关于安全性的。第2.3节讨论HTTP安全性是否足以满足特定应用程序的需要，第2.4节讨论新的基于HTTP的协议和防火墙之间的交互，第3节讨论使用单独的端口以避免防火墙，第4节讨论“s”的不足用于指定安全级别的URL前缀的后缀。
[1] 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.
[1] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[2] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[2] Franks，J.，Hallam Baker，P.，Hostetler，J.，Lawrence，S.，Leach，P.，Lootonen，A.和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 26171999年6月。
[3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[3] Dierks，T.和C.Allen，“TLS协议1.0版”，RFC 2246，1999年1月。
[4] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[4] Postel，J.和J.Reynolds，“Telnet协议规范”，STD 8，RFC 854，1983年5月。
[5] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[5] Postel，J.和J.Reynolds，“文件传输协议”，标准9，RFC 959，1985年10月。
[6] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[6] 《简单邮件传输协议》，RFC 28212001年4月。
[7] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[7] 迈尔斯，J.，“简单认证和安全层（SASL）”，RFC2222，1997年10月。
[8] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", BCP 35, RFC 2717, November 1999.
[8] Petke，R.和I.King，“URL方案名称的注册程序”，BCP 35，RFC 2717，1999年11月。
[9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[9] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[10] Howes, T., Smith, M. and F. Dawson, "A MIME Content-Type for Directory Information", RFC 2425, September 1998.
[10] Howes，T.，Smith，M.和F.Dawson，“目录信息的MIME内容类型”，RFC2425，1998年9月。
[11] Bray, T., Paoli, J. and C. Sperberg-McQueen, "Extensible Markup Language (XML)" World Wide Web Consortium Recommendation REC-xml-19980210, February 1998. http://www.w3.org/TR/1998/REC-xml-19980210.
[11] Bray，T.，Paoli，J.和C.Sperberg McQueen，“可扩展标记语言（XML）”，万维网联盟建议REC-XML-19980210，1998年2月。http://www.w3.org/TR/1998/REC-xml-19980210.
[12] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[12] Murata，M.，St.Laurent，S.和D.Kohn，“XML媒体类型”，RFC 3023，2001年1月。
Keith Moore University of Tennessee Computer Science Department 1122 Volunteer Blvd, Suite 203 Knoxville TN, 37996-3450 USA
基思穆尔田纳西大学计算机科学系1122志愿者BLVD，203诺克斯维尔TN套房，美国
EMail: moore@cs.utk.edu
EMail: moore@cs.utk.edu
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。