An overview of the

This article is the ninth chapter of WebSocket protocol. The main content of this article is WebSocket extension.

Those interested in the previous chapters of this document can see:

  • WebSocket Protocol — Abstract
  • WebSocket Protocol Chapter 1 — Introduction
  • WebSocket Protocol Chapter 2 — Conformance Requirements
  • WebSocket Protocol chapter 3 — WebSocket URIs
  • WebSocket Protocol chapter 4 — Opening Handshake
  • WebSocket Protocol Chapter 5 — Data Framing
  • Chapter 6 of the WebSocket Protocol — Sending and Receiving Data
  • WebSocket Protocol Chapter 7 — Closing the Connection
  • WebSocket Protocol Chapter 8 — Error Handling

Extension (Agreement body)

WebSocket can request extensions mentioned in this specification, and the WebSocket server can accept extensions requested by some or all of the clients. The server disallows responding to extensions not requested by the client. If the extension parameters need to be negotiated between the client and server, they must be selected according to the specification of the extension to which the parameters are applied.

9.1 Negotiation Extension

The client requests the extension through the sec-websocket-Extensions request header field, which complies with HTTP rules and whose value is defined by ABNF. Note that this section is implied through the ABNF syntax/rules, including the “implied *LWS rule”. If our client or server receives a value that does not comply with the following ABNF rules during the negotiation extension, the party receiving the wrong data needs to immediately tell WebSocket to close the connection.

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 quoted syntax variables, the value of the variable after the quoted character must conform to the 'token' variable ABNF specification.Copy the code

Note that, just like any other HTTP request header field, this request header field can be cut into several lines or merged into one line. Therefore, the following two paragraphs are equivalent:

Sec-WebSocket-Extensions: foo
Sec-WebSocket-Extensions: bar; baz=2
Copy the code

Is equivalent to:

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

Any extension certificate must be a registered certificate. (See bottom section 11.4). Any parameters used by the extension must be defined for the extension. Note that clients can only suggest using any existing extension and not use it unless the server indicates that they want to use the extension.

It is important to note the order of extension. Any interaction among multiple extensions can be defined in the document that defines the extension. In the absence of such a definition, the header fields listed by the client in its request represent the preferences for the header fields it wishes to use, with the first option listed being the most desirable. The extensions listed by the server in the response represent the extensions actually used by the connection. If the extension modifies data or frames, the order of operations on the data should be assumed to be the same as the order in the listed extension of the server response from which the link started.

For example, if there are two Extensions “foo” and “bar” and the server sends the sec-websocket-Extensions header with a value of “foo,bar”, the order of operations on the data is bar(foo(data)), Are changes to the data itself (such as compression) or changes to the “stacked” frames.

A non-normative example of an acceptable extended header field (note that long lines are folded for easy reading) is as follows:

Sec-WebSocket-Extensions: deflate-stream
Sec-WebSocket-Extensions: mux; max-channels=4; flow-control, deflate-stream
Sec-WebSocket-Extensions: private-extension
Copy the code

The server accepts one or more extension fields in the SEC-Websocket-Extensions header field extension that contains the client request. Any extension parameters that can be constructed through the server in response to parameters requested from the client will be defined by each extension.

9.2 Known Extensions

Extensions provide a mechanism for implementation by choosing to use additional functionality protocols. No extensions are defined in this document, but implementations span extensions that use separate definitions.