1. 扩展

WebSocket客户端可以请求对本规范的扩展，WebSocket服务器可以接受客户端请求的部分或全部扩展。服务器不得响应客户端未请求的任何扩展。如果客户端和服务器之间的协商中包含扩展参数，那么这些参数必须根据扩展的规范来选择。

9.1. 协商扩展

客户端通过包含一个|Sec-WebSocket-Extensions|头字段来请求扩展，该头字段遵循HTTP头字段的正常规则（参见[RFC2616]，第4.2节），头字段的值由以下ABNF [RFC2616]定义。请注意，本节使用的是[RFC2616]中的ABNF语法/规则，包括“隐含的*LWS规则”。如果客户端或服务器在协商过程中收到不符合以下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) ]
    ;使用quoted-string语法变体时，解码后的值必须符合'token' ABNF。

请注意，像其他HTTP头字段一样，此头字段可以跨多行分割或组合。因此，以下是等效的：

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

与

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

完全等效。

使用的任何extension-token必须是已注册的token（参见第11.4节）。提供给任何给定扩展的参数必须为该扩展定义。请注意，客户端仅提议使用任何公告的扩展，并且除非服务器表示希望使用该扩展，否则不得使用它们。

请注意，扩展的顺序很重要。多个扩展之间的任何交互可以在定义扩展的文档中定义。在没有这样的定义的情况下，解释是客户端在其请求中列出的头字段代表了它希望使用的头字段的偏好，列在前面的选项最为可取。服务器响应中列出的扩展代表了连接实际使用的扩展。如果扩展修改了数据和/或帧，那么对数据的操作顺序应该假定与服务器在开放握手中的响应中列出的扩展的顺序相同。

例如，如果有两个扩展“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

服务器通过包含一个包含客户端请求的一个或多个扩展的|Sec-WebSocket-Extensions|头字段来接受一个或多个扩展。任何扩展参数的解释，以及服务器对客户端请求的参数集的有效响应是什么，将由每个扩展定义。

9.2. 已知扩展

扩展为实现提供了选择加入额外协议功能的机制。本文档没有定义任何扩展，但实现可以使用单独定义的扩展。