-
Notifications
You must be signed in to change notification settings - Fork 58
IETF WebSocket Protocol
Eric Forgy edited this page Feb 15, 2018
·
10 revisions
This page will try to summarize where we stand as far as compliance with the IETF WebSockets Protocol.
| Section | Quote | Status (WebSockets) | Status (HTTP) |
|---|---|---|---|
| 1.3 | The Connection and Upgrade header fields complete the HTTP Upgrade. The Sec-WebSocket-Accept header field indicates whether the server is willing to accept the connection. If present, this header field must include a hash of the client's nonce sent in Sec-WebSocket-Key along with a predefined GUID. Any other value must not be interpreted as an acceptance of the connection by the server. |
❓ | ❓ |
| 3. | Fragment identifiers are meaningless in the context of WebSocket URIs and MUST NOT be used on these URIs. As with any URI scheme, the character "#", when not indicating the start of a fragment, MUST be escaped as %23. | ❓ | ❓ |
| 4.1 | When the client is to Establish a WebSocket Connection given a set (/host/, /port/, /resource name/, and /secure/ flag), along with a list of /protocols/ and /extensions/ to be used, and an /origin/ in the case of web browsers, it MUST open a connection, send an opening handshake, and read the server's handshake in response. | ❓ | ❓ |