RFC6455-The WebSocket protocol 之九：9. Extensions

9. Extensions

9.扩展
WebSocket clients MAY request extensions to this specification, and

WebSocket servers MAY accept some or all extensions requested by the

client. A server MUST NOT respond with any extension not requested

by the client. If extension parameters are included in negotiations

between the client and the server, those parameters MUST be chosen in

accordance with the specification of the extension to which the

parameters apply.

WebSocket 客户端可能会请求本说明书中提到的扩展，WebSocket 服务端可以接收部分或全部客户端请求的扩展。服务端必须不返回客户端没有请求的任何扩展。假如客户端和服务端交互过程中使用到了扩展字段，这些字段必须与说明书中的扩展保持一致。

9.1. Negotiating Extensions

9.1 交互扩展

A client requests extensions by including a |Sec-WebSocket-

Extensions| header field, which follows the normal rules for HTTP

header fields (see [RFC2616], Section 4.2) and the value of the

header field is defined by the following ABNF [RFC2616]. Note that

this section is using ABNF syntax/rules from [RFC2616], including the

"implied *LWS rule". If a value is received by either the client or

the server during negotiation that does not conform to the ABNF

below, the recipient of such malformed data MUST immediately _Fail

the WebSocket Connection_.

一个客户端通过Sec-WebSocket-Extensions头字段引入扩展字段，扩展字段遵循HTTP头字段的规则，头字段的值在后面的ABNF中定义。注意本节正在使用RFC2616中的ABNF语法，包含"implied *LWS rule"。假如交互过程中客户端或服务端接收到的值与ABNF不匹配，非法数据的接收方必须立即丢弃WebSocket连接。

Sec-WebSocket-Extensions = extension-list

extension-list = 1#extension

extension = extension-token *( ";" extension-param )

extension-token = registered-token

registered-token = token

extension-param = token [ "=" (token | quoted-string) ]

;When using the quoted-string syntax variant, the value

;after quoted-string unescaping MUST conform to the

;’token’ ABNF.

Note that like other HTTP header fields, this header field MAY be

split or combined across multiple lines. Ergo, the following are

equivalent:

与其它HTTP头字段一样，这些头字段在通过多样网络的时候可能被分割或合并。因此，下面的都是等价的：

Sec-WebSocket-Extensions: foo

Sec-WebSocket-Extensions: bar; baz=2

is exactly equivalent to

Sec-WebSocket-Extensions: foo, bar; baz=2

Any extension-token used MUST be a registered token (see

Section 11.4). The parameters supplied with any given extension MUST

be defined for that extension. Note that the client is only offering

to use any advertised extensions and MUST NOT use them unless the

server indicates that it wishes to use the extension.

任何被使用的扩展记号必须是已经注册的记号。任何给定的扩展提供的字段都必须是为该扩展定义的。注意，客户端只能使用开放的扩展，除非服务端暗示它将使用那个扩展，否则客户端不能使用它们。

Note that the order of extensions is significant. Any interactions

between multiple extensions MAY be defined in the documents defining

the extensions. In the absence of such definitions, the

interpretation is that the header fields listed by the client in its

request represent a preference of the header fields it wishes to use,

with the first options listed being most preferable. The extensions

listed by the server in response represent the extensions actually in

use for the connection. Should the extensions modify the data and/or

framing, the order of operations on the data should be assumed to be

the same as the order in which the extensions are listed in the

server’s response in the opening handshake.

注意扩展的顺序至关重要。任何扩展间的的交互必须在定义该扩展的文档中定义。在缺乏定义的情况下，客户端请求中列出的头字段代表了它偏好去使用的头字段，第一个选项是最可取的。服务端响应中列出的扩展代表的是本连接中实际用到的扩展。扩展是否应该修改数据或帧，对数据操作步骤的顺序应该与握手中服务端响应中列出的扩展的顺序保持一致。

For example, if there are two extensions "foo" and "bar" and if the

header field |Sec-WebSocket-Extensions| sent by the server has the

value "foo, bar", then operations on the data will be made as

bar(foo(data)), be those changes to the data itself (such as

compression) or changes to the framing that may "stack".

Non-normative examples of acceptable extension header fields (note

that long lines are folded for readability):

例如，假如这里有两个扩展“foo”和“bar”，而且服务端发送的头字段|Sec-WebSocket-Extensions| 中包含"foo, bar"，那么对数据的操作应该是bar(foo(data))，这些对数据本身或帧的改变就像“栈”一样。没有可接受的扩展头字段的规范例子。

Sec-WebSocket-Extensions: deflate-stream

Sec-WebSocket-Extensions: mux; max-channels=4; flow-control,deflate-stream

Sec-WebSocket-Extensions: private-extension

A server accepts one or more extensions by including a

|Sec-WebSocket-Extensions| header field containing one or more

extensions that were requested by the client. The interpretation of

any extension parameters, and what constitutes a valid response by a

server to a requested set of parameters by a client, will be defined

by each such extension.

一个服务端通过包含|Sec-WebSocket-Extensions| 头字段接收一个或多个扩展，该头字段中包含客户端请求的一个或多个扩展。一个服务端对任何扩展字段的解释，以及对客户端请求参数的有效响应，都必须通过这样的扩展定义。

9.2. Known Extensions

9.2 已知的扩展

Extensions provide a mechanism for implementations to opt-in to

additional protocol features. This document doesn’t define any

extension, but implementations MAY use extensions defined separately.

扩展为加入额外的协议特性实现定义了一个机制。本文档没有定义任何扩展，但是实现会使用各自定义的扩展。