错误处理8.1 处理编码错误的 UTF-8 数据当一端在以 UTF-8 编码解释接收到的数据，但是发现其实不是有效的 UTF-8 编码时，一端必须标记 WebSocket 连接为失败。这个规则适用于握手以及随后的数据传输阶段。
9. 扩展在这份技术说明中，客户端是可以请求使用扩展的，并且服务端可以受理客户端请求的扩展中的一个或者所有扩展。服务端响应的扩展必须属于客户端请求的扩展列表。如果扩展协商中包含了相应的扩展参数，那么参数的选择和应用必须按照具体的扩展的技术说明中描述的方式。
9.1 扩展协商客户端通过包含 |Sec-WebSocket-Extensions| 去请求扩展，此字段名遵循普通的 HTTP 头字段的规则 ，其内容的形式经由下面的 ABNF 表达式给出定义。注意，着一节中的 ABNF 语法规则遵循 ，包括了 “隐含的 *LWS 规则”。如果一端接收到的值不符合下面的 ABNF，那么接收端必须立刻标记 WebSocket 连接为失败。
[url=] [/url]
Sec-WebSocket-Extensions = extension-listextension-list = 1#extensionextension = extension-token *( ";" extension-param )extension-token = registered-tokenregistered-token = tokenextension-param = token [ "=" (token | quoted-string) ] ;When using the quoted-string syntax variant, the value after quoted-string unescaping MUST conform to the ;'token' ABNF.[url=][/url]
注意，和其他的 HTTP 头字段一样，这些头字段也可以分隔成多行，或者由多行合并。因此下面的两个是等价的：
Sec-WebSocket-Extensions: fooSec-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))，对于数据或者帧的修改过程看起来像是 “栈 stack”。
一个关于受理扩展头字段的非规范化的例子：
Sec-WebSocket-Extensions: deflate-streamSec-WebSocket-Extensions: mux; max-channels=4; flow-control, deflate-streamSec-WebSocket-Extensions: private-extension
服务端受理一个或者多个扩展，通过 |Sec-WebSocket-Extensions| 头字段包含一个或者多个来自客户端请求中的扩展。扩展参数的解释，以及服务端如何正确响应客户端的参数，都在各自扩展的定义中描述。
9.2 已知的扩展扩展提供了一个插件的机制，以提供额外的协议功能。这份文档没有定义任何的扩展，但是实现时可以使用独立定义在其他文档的扩展。 |
