Internet Engineering Task Force (IETF) P. McManus
Request for Comments: 8441 Mozilla
Updates: 6455 September 2018
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) P. McManus
Request for Comments: 8441 Mozilla
Updates: 6455 September 2018
Category: Standards Track
ISSN: 2070-1721
Bootstrapping WebSockets with HTTP/2
使用HTTP/2引导WebSocket
Abstract
摘要
This document defines a mechanism for running the WebSocket Protocol (RFC 6455) over a single stream of an HTTP/2 connection.
本文档定义了在HTTP/2连接的单个流上运行WebSocket协议（RFC6455）的机制。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8441.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8441.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The SETTINGS_ENABLE_CONNECT_PROTOCOL SETTINGS Parameter . . . 3
4. The Extended CONNECT Method . . . . . . . . . . . . . . . . . 4
5. Using Extended CONNECT to Bootstrap the WebSocket Protocol . 4
5.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Design Considerations . . . . . . . . . . . . . . . . . . . . 6
7. About Intermediaries . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9.1. A New HTTP/2 Setting . . . . . . . . . . . . . . . . . . 7
9.2. A New HTTP Upgrade Token . . . . . . . . . . . . . . . . 7
10. Normative References . . . . . . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The SETTINGS_ENABLE_CONNECT_PROTOCOL SETTINGS Parameter . . . 3
4. The Extended CONNECT Method . . . . . . . . . . . . . . . . . 4
5. Using Extended CONNECT to Bootstrap the WebSocket Protocol . 4
5.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Design Considerations . . . . . . . . . . . . . . . . . . . . 6
7. About Intermediaries . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9.1. A New HTTP/2 Setting . . . . . . . . . . . . . . . . . . 7
9.2. A New HTTP Upgrade Token . . . . . . . . . . . . . . . . 7
10. Normative References . . . . . . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
The Hypertext Transfer Protocol (HTTP) [RFC7230] provides compatible resource-level semantics across different versions, but it does not offer compatibility at the connection-management level. Other protocols that rely on connection-management details of HTTP, such as WebSockets, must be updated for new versions of HTTP.
超文本传输协议（HTTP）[RFC7230]提供了跨不同版本的兼容资源级别语义，但它不提供连接管理级别的兼容性。其他依赖HTTP连接管理详细信息的协议，如WebSockets，必须针对HTTP的新版本进行更新。
The WebSocket Protocol [RFC6455] uses the HTTP/1.1 Upgrade mechanism (Section 6.7 of [RFC7230]) to transition a TCP connection from HTTP into a WebSocket connection. A different approach must be taken with HTTP/2 [RFC7540]. Due to its multiplexing nature, HTTP/2 does not allow connection-wide header fields or status codes, such as the Upgrade and Connection request-header fields or the 101 (Switching Protocols) response code. These are all required by the [RFC6455] opening handshake.
WebSocket协议[RFC6455]使用HTTP/1.1升级机制（RFC7230的第6.7节）将TCP连接从HTTP转换为WebSocket连接。HTTP/2[RFC7540]必须采用不同的方法。由于其多路复用性质，HTTP/2不允许连接范围的报头字段或状态代码，例如升级和连接请求报头字段或101（交换协议）响应代码。这些都是[RFC6455]开场握手所需要的。
Being able to bootstrap WebSockets from HTTP/2 allows one TCP connection to be shared by both protocols and extends HTTP/2's more efficient use of the network to WebSockets.
能够从HTTP/2引导WebSocket允许两个协议共享一个TCP连接，并将HTTP/2更有效地使用网络扩展到WebSocket。
This document extends the HTTP CONNECT method, as specified for HTTP/2 in Section 8.3 of [RFC7540]. The extension allows the substitution of a new protocol name to connect to rather than the external host normally used by CONNECT. The result is a tunnel on a single HTTP/2 stream that can carry data for WebSockets (or any other protocol). The other streams on the connection may carry more extended CONNECT tunnels, traditional HTTP/2 data, or a mixture of both.
本文档扩展了[RFC7540]第8.3节中为HTTP/2指定的HTTP连接方法。扩展允许替换要连接的新协议名，而不是connect通常使用的外部主机。其结果是在单个HTTP/2流上形成一个隧道，可以为WebSocket（或任何其他协议）传输数据。连接上的其他流可能承载更多扩展的连接隧道、传统HTTP/2数据或两者的混合。
This tunneled stream will be multiplexed with other regular streams on the connection and enjoys the normal priority, cancellation, and flow-control features of HTTP/2.
此隧道流将与连接上的其他常规流多路复用，并享受HTTP/2的正常优先级、取消和流控制功能。
Streams that successfully establish a WebSocket connection using a tunneled stream and the modifications to the opening handshake defined in this document then use the traditional WebSocket Protocol, treating the stream as if it were the TCP connection in that specification.
使用隧道流和本文档中定义的对开始握手的修改成功建立WebSocket连接的流，然后使用传统的WebSocket协议，将该流视为该规范中的TCP连接。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
This document adds a new SETTINGS parameter to those defined by [RFC7540], Section 6.5.2.
本文件在[RFC7540]第6.5.2节定义的设置参数中添加了一个新的设置参数。
The new parameter name is SETTINGS_ENABLE_CONNECT_PROTOCOL. The value of the parameter MUST be 0 or 1.
新参数名为设置\启用\连接\协议。参数的值必须为0或1。
Upon receipt of SETTINGS_ENABLE_CONNECT_PROTOCOL with a value of 1, a client MAY use the Extended CONNECT as defined in this document when creating new streams. Receipt of this parameter by a server does not have any impact.
在收到值为1的设置\u启用\u连接\u协议后，客户端可以在创建新流时使用本文档中定义的扩展连接。服务器接收此参数不会产生任何影响。
A sender MUST NOT send a SETTINGS_ENABLE_CONNECT_PROTOCOL parameter with the value of 0 after previously sending a value of 1.
在先前发送值1后，发送方不得发送值为0的设置\启用\连接\协议参数。
Using a SETTINGS parameter to opt into an otherwise incompatible protocol change is a use of "Extending HTTP/2" defined by Section 5.5 of [RFC7540]. Specifically, the addition a new pseudo-header field, ":protocol", and the change in meaning of the :authority pseudo-header field in Section 4 require opt-in negotiation. If a client were to use the provisions of the extended CONNECT method defined in this document without first receiving a SETTINGS_ENABLE_CONNECT_PROTOCOL parameter, a non-supporting peer would detect a malformed request and generate a stream error (Section 8.1.2.6 of [RFC7540]).
使用设置参数选择其他不兼容的协议更改是使用[RFC7540]第5.5节定义的“扩展HTTP/2”。具体而言，添加新的伪头字段“：protocol”以及第4节中：authority伪头字段含义的更改需要选择加入协商。如果客户机使用本文档中定义的扩展连接方法的规定，而不首先接收设置\启用\连接\协议参数，则不支持的对等方将检测到格式错误的请求并生成流错误（RFC7540的第8.1.2.6节）。
Usage of the CONNECT method in HTTP/2 is defined by Section 8.3 of [RFC7540]. This extension modifies the method in the following ways:
[RFC7540]第8.3节定义了HTTP/2中连接方法的用法。此扩展通过以下方式修改该方法：
o A new pseudo-header field :protocol MAY be included on request HEADERS indicating the desired protocol to be spoken on the tunnel created by CONNECT. The pseudo-header field is single valued and contains a value from the "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" located at <https://www.iana.org/assignments/http-upgrade-tokens/>
o 一个新的伪头字段：protocol可能包含在请求头中，指示在CONNECT创建的隧道上所需的协议。伪标头字段是单值字段，包含位于的“超文本传输协议（HTTP）升级令牌注册表”中的值<https://www.iana.org/assignments/http-upgrade-tokens/>
o On requests that contain the :protocol pseudo-header field, the :scheme and :path pseudo-header fields of the target URI (see Section 5) MUST also be included.
o 在包含：protocol伪头字段的请求中，还必须包括目标URI的：scheme和：path伪头字段（参见第5节）。
o On requests bearing the :protocol pseudo-header field, the :authority pseudo-header field is interpreted according to Section 8.1.2.3 of [RFC7540] instead of Section 8.3 of that document. In particular, the server MUST NOT create a tunnel to the host indicated by the :authority as it would with a CONNECT method request that was not modified by this extension.
o 对于带有：协议伪头字段的请求，根据[RFC7540]第8.1.2.3节而不是该文档第8.3节解释：权限伪头字段。特别是，服务器不能像处理未被此扩展修改的连接方法请求那样创建到：authority所指示的主机的隧道。
Upon receiving a CONNECT request bearing the :protocol pseudo-header field, the server establishes a tunnel to another service of the protocol type indicated by the pseudo-header field. This service may or may not be co-located with the server.
在接收到带有：protocol pseudo header字段的连接请求后，服务器建立到另一个协议类型的隧道，该协议类型由pseudo header字段指示。此服务可能与服务器位于同一位置，也可能不与服务器位于同一位置。
The :protocol pseudo-header field MUST be included in the CONNECT request, and it MUST have a value of "websocket" to initiate a WebSocket connection on an HTTP/2 stream. Other HTTP request and response-header fields, such as those for manipulating cookies, may be included in the HEADERS with the CONNECT method as usual. This request replaces the GET-based request in [RFC6455] and is used to process the WebSockets opening handshake.
：protocol pseudo header字段必须包含在CONNECT请求中，并且其值必须为“websocket”，才能在HTTP/2流上启动websocket连接。其他HTTP请求和响应头字段，例如用于操纵cookie的字段，可以像往常一样使用CONNECT方法包含在头中。此请求替换[RFC6455]中基于GET的请求，并用于处理WebSocket开始握手。
The scheme of the target URI (Section 5.1 of [RFC7230]) MUST be "https" for "wss"-schemed WebSockets and "http" for "ws"-schemed WebSockets. The remainder of the target URI is the same as the WebSocket URI. The WebSocket URI is still used for proxy autoconfiguration. The security requirements for the HTTP/2 connection used by this specification are established by [RFC7540] for https requests and [RFC8164] for http requests.
目标URI的模式（RFC7230的第5.1节）对于“wss”模式的WebSocket必须是“https”，对于“ws”模式的WebSocket必须是“http”。目标URI的其余部分与WebSocket URI相同。WebSocket URI仍然用于代理自动配置。本规范使用的HTTP/2连接的安全要求由[RFC7540]针对https请求和[RFC8164]针对HTTP请求确定。
[RFC6455] requires the use of Connection and Upgrade header fields that are not part of HTTP/2. They MUST NOT be included in the CONNECT request defined here.
[RFC6455]需要使用不属于HTTP/2的连接和升级头字段。它们不能包含在此处定义的连接请求中。
[RFC6455] requires the use of a Host header field that is also not part of HTTP/2. The Host information is conveyed as part of the :authority pseudo-header field, which is required on every HTTP/2 transaction.
[RFC6455]需要使用不属于HTTP/2的主机头字段。主机信息作为：authority pseudo header字段的一部分传递，该字段在每个HTTP/2事务中都是必需的。
Implementations using this extended CONNECT to bootstrap WebSockets do not do the processing of the Sec-WebSocket-Key and Sec-WebSocket-Accept header fields of [RFC6455] as that functionality has been superseded by the :protocol pseudo-header field.
使用此扩展连接到引导WebSocket的实现不会处理[RFC6455]的Sec WebSocket密钥和Sec WebSocket Accept标头字段，因为该功能已被：protocol伪标头字段取代。
The Origin [RFC6454], Sec-WebSocket-Version, Sec-WebSocket-Protocol, and Sec-WebSocket-Extensions header fields are used in the CONNECT request and response-header fields as defined in [RFC6455]. Note that HTTP/1 header field names were case insensitive, whereas HTTP/2 requires they be encoded as lowercase.
原始[RFC6454]、Sec WebSocket版本、Sec WebSocket协议和Sec WebSocket Extensions标头字段用于[RFC6455]中定义的连接请求和响应标头字段。请注意，HTTP/1头字段名不区分大小写，而HTTP/2要求它们编码为小写。
After successfully processing the opening handshake, the peers should proceed with the WebSocket Protocol [RFC6455] using the HTTP/2 stream from the CONNECT transaction as if it were the TCP connection referred to in [RFC6455]. The state of the WebSocket connection at this point is OPEN, as defined by [RFC6455], Section 4.1.
成功处理开始握手后，对等方应使用CONNECT事务中的HTTP/2流继续使用WebSocket协议[RFC6455]，就像[RFC6455]中提到的TCP连接一样。根据[RFC6455]第4.1节的定义，此时的WebSocket连接状态为打开状态。
The HTTP/2 stream closure is also analogous to the TCP connection closure of [RFC6455]. Orderly TCP-level closures are represented as END_STREAM flags ([RFC7540], Section 6.1). RST exceptions are represented with the RST_STREAM frame ([RFC7540], Section 6.4) with the CANCEL error code ([RFC7540], Section 7).
HTTP/2流闭包也类似于[RFC6455]的TCP连接闭包。有序TCP级闭包表示为结束流标志（[RFC7540]，第6.1节）。RST异常由RST_流帧（[RFC7540]，第6.4节）和取消错误代码（[RFC7540]，第7节）表示。
[[ From Client ]] [[ From Server ]]
[[来自客户端]][[来自服务器]]
SETTINGS SETTINGS_ENABLE_CONNECT_[..] = 1
设置设置启用连接设置=1
HEADERS + END_HEADERS
:method = CONNECT
:protocol = websocket
:scheme = https
:path = /chat
:authority = server.example.com
sec-websocket-protocol = chat, superchat
sec-websocket-extensions = permessage-deflate
sec-websocket-version = 13
origin = http://www.example.com
HEADERS + END_HEADERS
:method = CONNECT
:protocol = websocket
:scheme = https
:path = /chat
:authority = server.example.com
sec-websocket-protocol = chat, superchat
sec-websocket-extensions = permessage-deflate
sec-websocket-version = 13
origin = http://www.example.com
HEADERS + END_HEADERS :status = 200 sec-websocket-protocol = chat
标题+结束标题：状态=200秒websocket协议=聊天
DATA WebSocket Data
数据WebSocket数据
DATA + END_STREAM WebSocket Data
数据+结束流WebSocket数据
DATA + END_STREAM WebSocket Data
数据+结束流WebSocket数据
A more native integration with HTTP/2 is certainly possible with larger additions to HTTP/2. This design was selected to minimize the solution complexity while still addressing the primary concern of running HTTP/2 and WebSockets concurrently.
通过对HTTP/2进行更大的添加，与HTTP/2进行更本机的集成当然是可能的。选择此设计是为了最小化解决方案的复杂性，同时仍然解决同时运行HTTP/2和WebSocket的主要问题。
This document does not change how WebSockets interacts with HTTP forward proxies. If a client wishing to speak WebSockets connects via HTTP/2 to an HTTP proxy, it should continue to use a traditional CONNECT (i.e., not with a :protocol pseudo-header field) to tunnel through that proxy to the WebSocket server via HTTP.
本文档不会更改WebSocket与HTTP转发代理交互的方式。如果希望使用WebSocket的客户端通过HTTP/2连接到HTTP代理，则应继续使用传统连接（即不使用：协议伪头字段）通过HTTP通过该代理隧道到WebSocket服务器。
The resulting version of HTTP on that tunnel determines whether WebSockets is initiated directly or via a modified CONNECT request described in this document.
该隧道上HTTP的最终版本决定是直接启动WebSocket还是通过本文档中描述的修改后的连接请求启动WebSocket。
[RFC6455] ensures that non-WebSockets clients, especially XMLHttpRequest-based clients, cannot make a WebSocket connection. Its primary mechanism for doing that is the use of Sec-prefixed request-header fields that cannot be created by XMLHttpRequest-based clients. This specification addresses that concern in two ways:
[RFC6455]确保非WebSocket客户端，尤其是基于XMLHttpRequest的客户端，无法建立WebSocket连接。其主要机制是使用基于XMLHttpRequest的客户端无法创建的带Sec前缀的请求头字段。本规范通过两种方式解决该问题：
o XMLHttpRequest also prohibits use of the CONNECT method in addition to Sec-prefixed request-header fields.
o XMLHttpRequest还禁止使用CONNECT方法以及Sec前缀的请求头字段。
o The use of a pseudo-header field is something that is connection specific, and HTTP/2 never allows a pseudo-header to be created outside of the protocol stack.
o 伪头字段的使用是特定于连接的，HTTP/2从不允许在协议栈之外创建伪头。
The security considerations of [RFC6455], Section 10 continue to apply to the use of the WebSocket Protocol when using this specification, with the exception of 10.8. That section is not relevant, because it is specific to the bootstrapping handshake that is changed in this document.
[RFC6455]第10节的安全注意事项继续适用于使用本规范时WebSocket协议的使用，10.8除外。该部分与此无关，因为它特定于本文档中更改的引导握手。
This document registers an entry in the "HTTP/2 Settings" registry that was established by Section 11.3 of [RFC7540].
本文件在[RFC7540]第11.3节建立的“HTTP/2设置”注册表中注册了一个条目。
Code: 0x8 Name: SETTINGS_ENABLE_CONNECT_PROTOCOL Initial Value: 0 Specification: This document
代码：0x8名称：设置\u启用\u连接\u协议初始值：0规范：此文档
This document registers an entry in the "HTTP Upgrade Tokens" registry that was established by [RFC7230].
本文档在[RFC7230]建立的“HTTP升级令牌”注册表中注册一个条目。
Value: websocket Description: The Web Socket Protocol Expected Version Tokens: References: [RFC6455] [RFC8441]
值：websocket说明：Web套接字协议预期的版本标记：引用：[RFC6455][RFC8441]
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, December 2011, <https://www.rfc-editor.org/info/rfc6454>.
[RFC6454]Barth，A.，“网络起源概念”，RFC 6454，DOI 10.17487/RFC6454，2011年12月<https://www.rfc-editor.org/info/rfc6454>.
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, DOI 10.17487/RFC6455, December 2011, <https://www.rfc-editor.org/info/rfc6455>.
[RFC6455]Fette，I.和A.Melnikov，“WebSocket协议”，RFC 6455，DOI 10.17487/RFC6455，2011年12月<https://www.rfc-editor.org/info/rfc6455>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<https://www.rfc-editor.org/info/rfc7230>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, <https://www.rfc-editor.org/info/rfc7540>.
[RFC7540]Belshe，M.，Paon，R.，和M.Thomson，编辑，“超文本传输协议版本2（HTTP/2）”，RFC 7540，DOI 10.17487/RFC7540，2015年5月<https://www.rfc-editor.org/info/rfc7540>.
[RFC8164] Nottingham, M. and M. Thomson, "Opportunistic Security for HTTP/2", RFC 8164, DOI 10.17487/RFC8164, May 2017, <https://www.rfc-editor.org/info/rfc8164>.
[RFC8164]诺丁汉，M.和M.汤姆森，“HTTP/2的机会主义安全”，RFC 8164，DOI 10.17487/RFC8164，2017年5月<https://www.rfc-editor.org/info/rfc8164>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
Acknowledgments
致谢
The 2017 HTTP Workshop had a very productive discussion that helped determine the key problem and acceptable level of solution complexity.
2017年HTTP研讨会进行了富有成效的讨论，帮助确定了关键问题和解决方案复杂性的可接受水平。
Author's Address
作者地址
Patrick McManus Mozilla
帕特里克·麦克马纳斯·莫齐拉
Email: mcmanus@ducksong.com
Email: mcmanus@ducksong.com