9. Extensions
9.擴展
WebSocket clients MAY request extensions to this specification, and
WebSocket servers MAY accept some or all extensions requested by theclient. 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-listextension-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.
擴展爲加入額外的協議特性實現定義了一個機制。本文檔沒有定義任何擴展，但是實現會使用各自定義的擴展。