RFC6455-The WebSocket protocol 之十一(终结版):11. IANA Considerations

11. IANA Considerations

11.IANA的考虑

11.1. Registration of New URI Schemes
11.1 新URI结构(Schemes)注册

11.1.1. Registration of "ws" Scheme
A |ws| URI identifies a WebSocket server and resource name.
URI scheme name
ws
Status
Permanent
URI scheme syntax
Using the ABNF [RFC5234] syntax and ABNF terminals from the URI
specification [RFC3986]:
"ws:" "//" authority path-abempty [ "?" query ]
The <path-abempty> and <query> [RFC3986] components form the resource
name sent to the server to identify the kind of service desired.
Other components have the meanings described in [RFC3986].
URI scheme semantics
The only operation for this scheme is to open a connection using
the WebSocket Protocol.
Encoding considerations
Characters in the host component that are excluded by the syntax
defined above MUST be converted from Unicode to ASCII as specified
in [RFC3987] or its replacement. For the purposes of scheme-based
normalization, Internationalized Domain Name (IDN) forms of the
host component and their conversions to punycode are considered

equivalent (see Section 5.3.3 of [RFC3987]).

Characters in other components that are excluded by the syntax
defined above MUST be converted from Unicode to ASCII by first
encoding the characters as UTF-8 and then replacing the
corresponding bytes using their percent-encoded form as defined in
the URI [RFC3986] and Internationalized Resource Identifier (IRI)
[RFC3987] specifications.
Applications/protocols that use this URI scheme name
WebSocket Protocol
Interoperability considerations
Use of WebSocket requires use of HTTP version 1.1 or higher.
Security considerations
See "Security Considerations" section.
Contact
HYBI WG <hybi@ietf.org>
Author/Change controller
IETF <iesg@ietf.org>
References
RFC 6455
11.1.1 "ws"结构的注册

一个ws URI定义了一个WebSocket服务器和资源名称。
URI结构名称
ws
状态
永久的

URI结构语法
使用ABNF的语法和URI说明书中定义的字符:
"ws:" "//" authority path-abempty [ "?" query ]
<path-abempty> 和 <query>标志着发往服务器的期待的资源名称。其它部分与[RFC3986]中描述的一致。

URI结构语义
这个结构的唯一操作就是使用WebSocket协议打开服务端的连接。

编码注意事项
主机组件中被上面语法排除的字符必须从unicode转成ASCII,就像[RFC3987]或其替代品中定义的那样。为了保证基于结构的规范化,IDN行成了主机组件和域名转换被认为是同等的。
其它组件中被上面语法排除的字符也必须从unicode转成ASCII,但是首先要把字符转成UTF-8,然后使用URI和IRI中定义的部分编码的形式替换掉对应的字节。

应用/协议 使用的URI结构名称
WebSocket协议

通用性要求
使用WebSocket需要HTTP v1.1以上。

安全性要求
参照“安全性要求”节。

联系
HYBI WG <hybi@ietf.org>

作者/改变 总管
IETF <iesg@ietf.org>

引用
RFC 6455

11.1.2. Registration of "wss" Scheme
A |wss| URI identifies a WebSocket server and resource name and
indicates that traffic over that connection is to be protected via
TLS (including standard benefits of TLS such as data confidentiality
and integrity and endpoint authentication).
URI scheme name
wss
Status
Permanent
URI scheme syntax
Using the ABNF [RFC5234] syntax and ABNF terminals from the URI
specification [RFC3986]:
"wss:" "//" authority path-abempty [ "?" query ]
The <path-abempty> and <query> components form the resource name sent
to the server to identify the kind of service desired. Other
components have the meanings described in [RFC3986].

URI scheme semantics
The only operation for this scheme is to open a connection using
the WebSocket Protocol, encrypted using TLS.
Encoding considerations
Characters in the host component that are excluded by the syntax
defined above MUST be converted from Unicode to ASCII as specified
in [RFC3987] or its replacement. For the purposes of scheme-based
normalization IDN forms of the host component and their
conversions to punycode are considered equivalent (see Section
5.3.3 of [RFC3987]).
Characters in other components that are excluded by the syntax
defined above MUST be converted from Unicode to ASCII by first
encoding the characters as UTF-8 and then replacing the
corresponding bytes using their percent-encoded form as defined in
the URI [RFC3986] and IRI [RFC3987] specifications.
Applications/protocols that use this URI scheme name
WebSocket Protocol over TLS
Interoperability considerations
Use of WebSocket requires use of HTTP version 1.1 or higher.
Security considerations
See "Security Considerations" section.
Contact
HYBI WG <hybi@ietf.org>
Author/Change controller
IETF <iesg@ietf.org>
References
RFC 6455
11.1.2 “wss”结构的注册
一个wss URI定义了一个Websocket服务器和资源名称,而且暗示着在这个连接上的传输受到TLS的保护(包含TLS的标准优势,例如数据保密、数据完整、终端验证等)。
URI 结构名称
wss

状态
永久的

URI 结构语法
使用ABNF语法和URI说明书中的定义的字符:
"wss:" "//" authority path-abempty [ "?" query ]

<path-abempty> 和 <query>标志着发往服务器的期待的资源名称。其它部分与[RFC3986]中描述的一致。

URI结构语义
这个结构的唯一操作就是使用WebSocket协议打开服务端的连接,使用TLS加密。

编码注意事项
主机组件中被上面语法排除的字符必须从unicode转成ASCII,就像[RFC3987]或其替代品中定义的那样。为了保证基于结构的规范化,IDN行成了主机组件和域名转换被认为是同等的。
其它组件中被上面语法排除的字符也必须从unicode转成ASCII,但是首先要把字符转成UTF-8,然后使用URI和IRI中定义的部分编码的形式替换掉对应的字节。

应用/协议 使用的URI结构名称
基于TLS的WebSocket协议

通用性要求
使用WebSocket需要HTTP v1.1以上。

安全性要求
参照“安全性要求”节。

联系
HYBI WG <hybi@ietf.org>

作者/改变 总管
IETF <iesg@ietf.org>

引用
RFC 6455


11.2. Registration of the "WebSocket" HTTP Upgrade Keyword
This section defines a keyword registered in the HTTP Upgrade Tokens
Registry as per RFC 2817 [RFC2817].
Name of token
WebSocket
Author/Change controller
IETF <iesg@ietf.org>

Contact
HYBI <hybi@ietf.org>
References
RFC 6455
11.2 WebSocket HTTP Upgrade关键字注册
这节定义了一个在HTTP Upgrade Tokens中注册的关键字。
标志名称
WebSocket

联系
HYBI WG <hybi@ietf.org>

作者/改变 总管
IETF <iesg@ietf.org>

引用
RFC 6455

11.3. Registration of New HTTP Header Fields
11.3 新HTTP 头字段的注册

11.3.1. Sec-WebSocket-Key
This section describes a header field registered in the Permanent
Message Header Field Names registry [RFC3864].
Header field name
Sec-WebSocket-Key
Applicable protocol
http
Status
standard
Author/Change controller
IETF
Specification document(s)
RFC 6455
Related information
This header field is only used for WebSocket opening handshake.
The |Sec-WebSocket-Key| header field is used in the WebSocket opening
handshake. It is sent from the client to the server to provide part
of the information used by the server to prove that it received a
valid WebSocket opening handshake. This helps ensure that the server
does not accept connections from non-WebSocket clients (e.g., HTTP
clients) that are being abused to send data to unsuspecting WebSocket
servers.
The |Sec-WebSocket-Key| header field MUST NOT appear more than once
in an HTTP request.
11.3.1 Sec-WebSocket-Key
本节描述一个在永久消息头字段名称库中定义的头字段。
头字段名称
Sec-WebSocket-Key

可适用的协议
http

状态
标准

作者/改变 总管

IETF

说明书文档
RFC 6455

相关信息
这个头字段仅仅用在WebSocket握手。

Sec-WebSocket-Key头字段被用在打开WebSocket握手。它从客户端发往服务端,提供给服务端用以证明是合法WebSocket握手的部分信息。这帮助确认服务端没有从非WebSocket客户端接收请求,这正在被滥用发送数据到受信任的WebSocket服务端。
Sec-WebSocket-Key在HTTP 请求中只能出现一次。

11.3.2. Sec-WebSocket-Extensions

This section describes a header field for registration in the
Permanent Message Header Field Names registry [RFC3864].
Header field name
Sec-WebSocket-Extensions
Applicable protocol
http
Status
standard
Author/Change controller
IETF
Specification document(s)
RFC 6455
Related information
This header field is only used for WebSocket opening handshake.
The |Sec-WebSocket-Extensions| header field is used in the WebSocket
opening handshake. It is initially sent from the client to the
server, and then subsequently sent from the server to the client, to
agree on a set of protocol-level extensions to use for the duration
of the connection.
The |Sec-WebSocket-Extensions| header field MAY appear multiple times
in an HTTP request (which is logically the same as a single
|Sec-WebSocket-Extensions| header field that contains all values.
However, the |Sec-WebSocket-Extensions| header field MUST NOT appear
more than once in an HTTP response.
11.3.2. Sec-WebSocket-Extensions

本节描述一个在永久消息头字段名称库中定义的头字段。
头字段名称
Sec-WebSocket-Extensions

可适用的协议
http

状态
标准

作者/改变 总管

IETF

说明书文档
RFC 6455

相关信息
这个头字段仅仅用在WebSocket握手。

Sec-WebSocket-Extensions 头字段被用在打开WebSocket握手。它首先从客户端发往服务端,然后服务端把一部分返回给客户端,提供一套在连接过程中使用的协议级别的扩展。 Sec-WebSocket-Extensions在HTTP 请求中可能出现多次(在逻辑上来说它与一个包含所有内容的Sec-WebSocket-Extensions是一样的)。但是Sec-WebSocket-Extensions在HTTP响应中只能出现一次。

11.3.3. Sec-WebSocket-Accept
This section describes a header field registered in the Permanent
Message Header Field Names registry [RFC3864].
Header field name
Sec-WebSocket-Accept
Applicable protocol
http
Status
standard

Author/Change controller
IETF
Specification document(s)
RFC 6455
Related information
This header field is only used for the WebSocket opening
handshake.
The |Sec-WebSocket-Accept| header field is used in the WebSocket
opening handshake. It is sent from the server to the client to
confirm that the server is willing to initiate the WebSocket
connection.
The |Sec-WebSocket-Accept| header MUST NOT appear more than once in
an HTTP response.

本节描述一个在永久消息头字段名称库中定义的头字段。
头字段名称
Sec-WebSocket-Accept

可适用的协议
http

状态
标准

作者/改变 总管

IETF

说明书文档
RFC 6455

相关信息
这个头字段仅仅用在WebSocket握手。

Sec-WebSocket-Extensions 头字段被用在打开WebSocket握手。它从服务端发往客户端以证明服务端正打算初始化这个连接 Sec-WebSocket-Extensions在HTTP响应中只能出现一次。


11.3.4. Sec-WebSocket-Protocol
This section describes a header field registered in the Permanent
Message Header Field Names registry [RFC3864].
Header field name
Sec-WebSocket-Protocol
Applicable protocol
http
Status
standard
Author/Change controller
IETF
Specification document(s)
RFC 6455
Related information
This header field is only used for the WebSocket opening
handshake.
The |Sec-WebSocket-Protocol| header field is used in the WebSocket
opening handshake. It is sent from the client to the server and back
from the server to the client to confirm the subprotocol of the
connection. This enables scripts to both select a subprotocol and be
sure that the server agreed to serve that subprotocol.

The |Sec-WebSocket-Protocol| header field MAY appear multiple times
in an HTTP request (which is logically the same as a single
|Sec-WebSocket-Protocol| header field that contains all values).
However, the |Sec-WebSocket-Protocol| header field MUST NOT appear
more than once in an HTTP response.

本节描述一个在永久消息头字段名称库中定义的头字段。
头字段名称
Sec-WebSocket-Protocol

可适用的协议
http

状态
标准

作者/改变 总管

IETF

说明书文档
RFC 6455

相关信息
这个头字段仅仅用在WebSocket握手。

Sec-WebSocket-Protocol 头字段被用在打开WebSocket握手。它从客户端发往服务端然后从服务端返回到客户端以确定连接的子协议 。这即允许脚本去选择一个子协议又确定服务端同意支持这个子协议。Sec-WebSocket-Protocol在HTTP 请求中可能出现多次(在逻辑上来说它与一个包含所有内容的Sec-WebSocket-Protocol是一样的)。但是Sec-WebSocket-Protocol在HTTP响应中只能出现一次。


11.3.5. Sec-WebSocket-Version
This section describes a header field registered in the Permanent
Message Header Field Names registry [RFC3864].
Header field name
Sec-WebSocket-Version
Applicable protocol
http
Status
standard
Author/Change controller
IETF
Specification document(s)
RFC 6455
Related information
This header field is only used for the WebSocket opening
handshake.
The |Sec-WebSocket-Version| header field is used in the WebSocket
opening handshake. It is sent from the client to the server to
indicate the protocol version of the connection. This enables
servers to correctly interpret the opening handshake and subsequent
data being sent from the data, and close the connection if the server
cannot interpret that data in a safe manner. The |Sec-WebSocket-
Version| header field is also sent from the server to the client on
WebSocket handshake error, when the version received from the client
does not match a version understood by the server. In such a case,
the header field includes the protocol version(s) supported by the
server.
Note that there is no expectation that higher version numbers are
necessarily backward compatible with lower version numbers.

The |Sec-WebSocket-Version| header field MAY appear multiple times in
an HTTP response (which is logically the same as a single
|Sec-WebSocket-Version| header field that contains all values).
However, the |Sec-WebSocket-Version| header field MUST NOT appear
more than once in an HTTP request.

本节描述一个在永久消息头字段名称库中定义的头字段。
头字段名称
Sec-WebSocket-Version

可适用的协议
http

状态
标准

作者/改变 总管

IETF

说明书文档
RFC 6455

相关信息
这个头字段仅仅用在WebSocket握手。

Sec-WebSocket-Version 头字段被用在打开WebSocket握手。它从客户端发往服务端以确定连接的协议版本。这确保服务端可以正确的解析打开的握手和随后的数据,一旦服务端不能以安全的方式解析数据它就会关闭连接。当从客户端接收到的版本与服务端能理解的版本不一致时,Sec-WebSocket-Version在WebSocket握手失败的时候也会从服务端发往客户端。这时候该字段代表的是服务端支持的版本。 注意这里并没有要求高版本向下兼容低版本。

Sec-WebSocket-Version在HTTP 请求中可能出现多次(在逻辑上来说它与一个包含所有内容的Sec-WebSocket-Version是一样的)。但是Sec-WebSocket-Protocol在HTTP请求中只能出现一次。

11.4. WebSocket Extension Name Registry
This specification creates a new IANA registry for WebSocket
Extension names to be used with the WebSocket Protocol in accordance
with the principles set out in RFC 5226 [RFC5226].
As part of this registry, IANA maintains the following information:
Extension Identifier
The identifier of the extension, as will be used in the
|Sec-WebSocket-Extensions| header field registered in
Section 11.3.2 of this specification. The value must conform to
the requirements for an extension-token as defined in Section 9.1
of this specification.
Extension Common Name
The name of the extension, as the extension is generally referred
to.
Extension Definition
A reference to the document in which the extension being used with
the WebSocket Protocol is defined.
Known Incompatible Extensions
A list of extension identifiers with which this extension is known
to be incompatible.
WebSocket Extension names are to be subject to the "First Come First
Served" IANA registration policy [RFC5226].
There are no initial values in this registry.

11.4 WebSocket Extension Name Resitry
本说明书为WebSocket 扩展名称提供了一个新的IANA注册,这个扩展与WebSocket协议一块使用,与RFC 5226中定义的原则保持一致。作为注册的一部分,IANA包含以下的信息:

    扩展标记

        是扩展的标记,会在本书的11.3.2节中注册的|Sec-WebSocket-Extensions|头字段中使用到。它的值必须满足扩展符号(extension-token)的要求,就像说明书中9.1节定义的那样。

    扩展通用名称
        扩展的名称,就像扩展通常所引用的。
    扩展定义
        WebSocket 协议使用的扩展的定义文档。
    已知的不可用的扩展
        已知的不可用的扩展标识列表
    WebSocket扩展名称遵循IANA注册协议:第一个来的第一个提供服务

   
11.5. WebSocket Subprotocol Name Registry
This specification creates a new IANA registry for WebSocket
Subprotocol names to be used with the WebSocket Protocol in
accordance with the principles set out in RFC 5226 [RFC5226].

As part of this registry, IANA maintains the following information:
Subprotocol Identifier
The identifier of the subprotocol, as will be used in the
|Sec-WebSocket-Protocol| header field registered in Section 11.3.4
of this specification. The value must conform to the requirements
given in item 10 of Section 4.1 of this specification -- namely,
the value must be a token as defined by RFC 2616 [RFC2616].
Subprotocol Common Name
The name of the subprotocol, as the subprotocol is generally
referred to.
Subprotocol Definition
A reference to the document in which the subprotocol being used
with the WebSocket Protocol is defined.
WebSocket Subprotocol names are to be subject to the "First Come
First Served" IANA registration policy [RFC5226].
11.5 WebSocket Subprotocol Name 注册
本节为WebSocket 协议创造一个新的IANA注册,WebSocket Subprotocol与WebSocket协议一块使用,与RFC 5226中定义的原则保持一致。作为注册的一部分,IANA包含以下的信息:

Subprotocol标记

是子协议的标记,会在本书的11.3.4节中注册的|Sec-WebSocket-Protocol|头字段中使用到。它的值必须与本说明书中4.1节第10部分描述的一致,它的值必须是RFC 2616中定义的。

    Subprotocol通用名称
        Subprotocol的名称,就像Subprotocol通常所引用的。
    Subprotocol定义
        WebSocket 协议使用的Subprotocol的定义文档。
    WebSocket扩展名称遵循IANA注册协议:第一个来的第一个提供服务


11.6. WebSocket Version Number Registry

11.6 WebSocket 版本数字注册
This specification creates a new IANA registry for WebSocket Version
Numbers to be used with the WebSocket Protocol in accordance with the
principles set out in RFC 5226 [RFC5226].
As part of this registry, IANA maintains the following information:
Version Number
The version number to be used in the |Sec-WebSocket-Version| is
specified in Section 4.1 of this specification. The value must be
a non-negative integer in the range between 0 and 255 (inclusive).

Reference
The RFC requesting a new version number or a draft name with
version number (see below).
Status
Either "Interim" or "Standard". See below for description.
A version number is designated as either "Interim" or "Standard".
A "Standard" version number is documented in an RFC and used to
identify a major, stable version of the WebSocket protocol, such as
the version defined by this RFC. "Standard" version numbers are
subject to the "IETF Review" IANA registration policy [RFC5226].

An "Interim" version number is documented in an Internet-Draft and
used to help implementors identify and interoperate with deployed
versions of the WebSocket protocol, such as versions developed before
the publication of this RFC. "Interim" version numbers are subject
to the "Expert Review" IANA registration policy [RFC5226], with the
chairs of the HYBI Working Group (or, if the working group closes,
the Area Directors for the IETF Applications Area) being the initial
Designated Experts.
IANA has added initial values to the registry as follows.


本节为WebSocket 协议创造一个新的IANA注册,WebSocket Version Numbers与WebSocket协议一块使用,与RFC 5226中定义的原则保持一致。作为注册的一部分,IANA包含以下的信息:

    版本号
        版本号用在4.1节中介绍的|Sec-WebSocket-Version|中。值必须是介于0和255之间的整数。
    引用
        RFC要求一个新的版本号或带有版本号的草稿名。
    状态
        “过渡期”或“正式版”,看下面的描述。
        “正式版”的版本号在RFC中定义,用来标识WebSocket协议的一个重要的、稳定的版本,就像本RFC中定义的版本。“正式版”的版本号遵从IANA中定义的"IETF Review"。
        “过渡期”版本在“网络-草案”中定义,用来帮助开发人员标识和区分已经部署的WebSocket 协议,例如在RFC发布之前开发的版本。“过渡期”的版本号遵从IANA中定义的"Expert Review",HYBI Working Group是其初始设计团队。
        IANA已经增加的过渡期的值如下所示:

11.7. WebSocket Close Code Number Registry
This specification creates a new IANA registry for WebSocket
Connection Close Code Numbers in accordance with the principles set
out in RFC 5226 [RFC5226].
As part of this registry, IANA maintains the following information:
Status Code
The Status Code denotes a reason for a WebSocket connection
closure as per Section 7.4 of this document. The status code is
an integer number between 1000 and 4999 (inclusive).
Meaning
The meaning of the status code. Each status code has to have a
unique meaning.
Contact
A contact for the entity reserving the status code.
Reference
The stable document requesting the status codes and defining their
meaning. This is required for status codes in the range 1000-2999
and recommended for status codes in the range 3000-3999.
WebSocket Close Code Numbers are subject to different registration
requirements depending on their range. Requests for status codes for
use by this protocol and its subsequent versions or extensions are
subject to any one of the "Standards Action", "Specification
Required" (which implies "Designated Expert"), or "IESG Review" IANA
registration policies and should be granted in the range 1000-2999.
Requests for status codes for use by libraries, frameworks, and
applications are subject to the "First Come First Served" IANA
registration policy and should be granted in the range 3000-3999.
The range of status codes from 4000-4999 is designated for Private
Use. Requests should indicate whether they are requesting status
codes for use by the WebSocket Protocol (or a future version of the
protocol), by extensions, or by libraries/frameworks/applications.
IANA has added initial values to the registry as follows.
11.7 WebSocket 关闭码注册
本节创造了一个新的IANA注册,用来作为WebSocket连接关闭码,这与RFC5226中定义的一致。作为注册的一部分,IANa包含以下信息:
状态码:
一个状态码暗示了一种WebSocket连接关闭的原因,就像7.4节中描述的。这个状态码是介于1000到4999之间的整数。
含义:
状态码的含义。每一个状态码必须只有一个意义。
联系人
保留状态码的联系人。
引用
正式的文档要求状态码并定义了它的含义。对于1000-2999之间的状态码是必须的,对于3000-3999之间的状态码是推荐的。
WebSocket关闭码在不同的范围内对他们的限制是不同的。本协议、后面的版本或扩展版本使用的状态码要求遵从"Standards Action", "Specification Required"或IANA中的"IESG Review",允许在1000-2999之间。库、框架、应用使用的状态码要求遵循IANa的“先来先服务”原则,允许在3000-3999之间。4000-4999之间的状态码是用来做私有使用的。请求需要表明状态码是否使用在WebSocket协议上,或者扩展上,或者库/框架/应用上。IANA已经定义了一些初始的值:


11.8. WebSocket Opcode Registry
This specification creates a new IANA registry for WebSocket Opcodes
in accordance with the principles set out in RFC 5226 [RFC5226].
As part of this registry, IANA maintains the following information:
Opcode
The opcode denotes the frame type of the WebSocket frame, as
defined in Section 5.2. The opcode is an integer number between 0
and 15, inclusive.
Meaning
The meaning of the opcode value.

Reference
The specification requesting the opcode.
WebSocket Opcode numbers are subject to the "Standards Action" IANA
registration policy [RFC5226].
IANA has added initial values to the registry as follows.
11.8 WebSocket 操作码注册
本节创建了一个新的IANA注册项,用在WebSocket操作码,与RFC5225保持一致。作为注册项的一部分,IANA包含以下的信息:
操作码
    操作码定义了WebSocket帧的帧类型,就像5.2节中定义的。操作码是介于0-15之间的整数。
含义
    操作码的含义
引用
    规范要求操作码。
    WebSocket操作码与RFC5225中的IANA注册协议的"Standards Action"保持一致。
    IANa已经定义了一些初始值:
|Opcode | Meaning | Reference |
-+--------+-------------------------------------+-----------|
| 0 | Continuation Frame | RFC 6455 |
-+--------+-------------------------------------+-----------|
| 1 | Text Frame | RFC 6455 |
-+--------+-------------------------------------+-----------|
| 2 | Binary Frame | RFC 6455 |
-+--------+-------------------------------------+-----------|
| 8 | Connection Close Frame | RFC 6455 |
-+--------+-------------------------------------+-----------|
| 9 | Ping Frame | RFC 6455 |
-+--------+-------------------------------------+-----------|
| 10 | Pong Frame | RFC 6455 |
-+--------+-------------------------------------+-----------|
11.9. WebSocket Framing Header Bits Registry
This specification creates a new IANA registry for WebSocket Framing
Header Bits in accordance with the principles set out in RFC 5226
[RFC5226]. This registry controls assignment of the bits marked
RSV1, RSV2, and RSV3 in Section 5.2.
These bits are reserved for future versions or extensions of this
specification.
WebSocket Framing Header Bits assignments are subject to the
"Standards Action" IANA registration policy [RFC5226].
11.9WebSocket Framing Header Bits Registry
本节创建了一个新的IANA注册项,用在WebSocket 帧头比特,与RFC5225保持一致。这个注册项决定了在5.2中定义的RSV1、RSV2、RSV3的作用。
这些“位”给将来的版本或扩展而保留。
WebSocket Framing Header Bits与IANA中的"Standards Action"保持一致。

本节之后的内容,与WebSocket本身就没多大关系了,历时将近一个月的WebSocket翻译工作就告一段落了。虽然翻译的过程比较痛苦,虽然翻译的质量有待提高,但是培养这种从头到尾坚持到底的精神,正是本次翻译的目标。很高兴,我坚持下来了,我为自己加油。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值