< draft-ietf-hybi-thewebsocketprotocol-10.txt   draft-ietf-hybi-thewebsocketprotocol-11.txt >
HyBi Working Group I. Fette HyBi Working Group I. Fette
Internet-Draft Google, Inc. Internet-Draft Google, Inc.
Intended status: Standards Track A. Melnikov Intended status: Standards Track A. Melnikov
Expires: January 12, 2012 Isode Ltd Expires: February 24, 2012 Isode Ltd
July 11, 2011 August 23, 2011
The WebSocket protocol The WebSocket protocol
draft-ietf-hybi-thewebsocketprotocol-10 draft-ietf-hybi-thewebsocketprotocol-11
Abstract Abstract
The WebSocket protocol enables two-way communication between a client The WebSocket protocol enables two-way communication between a client
running untrusted code running in a controlled environment to a running untrusted code running in a controlled environment to a
remote host that has opted-in to communications from that code. The remote host that has opted-in to communications from that code. The
security model used for this is the Origin-based security model security model used for this is the Origin-based security model
commonly used by Web browsers. The protocol consists of an opening commonly used by Web browsers. The protocol consists of an opening
handshake followed by basic message framing, layered over TCP. The handshake followed by basic message framing, layered over TCP. The
goal of this technology is to provide a mechanism for browser-based goal of this technology is to provide a mechanism for browser-based
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 12, 2012. This Internet-Draft will expire on February 24, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 4 1.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 4
1.3. Opening Handshake . . . . . . . . . . . . . . . . . . . . 6 1.3. Opening Handshake . . . . . . . . . . . . . . . . . . . . 6
1.4. Closing Handshake . . . . . . . . . . . . . . . . . . . . 9 1.4. Closing Handshake . . . . . . . . . . . . . . . . . . . . 9
1.5. Design Philosophy . . . . . . . . . . . . . . . . . . . . 9 1.5. Design Philosophy . . . . . . . . . . . . . . . . . . . . 9
1.6. Security Model . . . . . . . . . . . . . . . . . . . . . 10 1.6. Security Model . . . . . . . . . . . . . . . . . . . . . . 10
1.7. Relationship to TCP and HTTP . . . . . . . . . . . . . . 11 1.7. Relationship to TCP and HTTP . . . . . . . . . . . . . . . 11
1.8. Establishing a Connection . . . . . . . . . . . . . . . . 11 1.8. Establishing a Connection . . . . . . . . . . . . . . . . 11
1.9. Subprotocols Using the WebSocket protocol . . . . . . . . 11 1.9. Subprotocols Using the WebSocket protocol . . . . . . . . 11
2. Conformance Requirements . . . . . . . . . . . . . . . . . . . 13 2. Conformance Requirements . . . . . . . . . . . . . . . . . . . 13
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 13 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 13
3. WebSocket URIs . . . . . . . . . . . . . . . . . . . . . . . . 15 3. WebSocket URIs . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Data Framing . . . . . . . . . . . . . . . . . . . . . . . . . 16 4. Data Framing . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2. Base Framing Protocol . . . . . . . . . . . . . . . . . . 16 4.2. Base Framing Protocol . . . . . . . . . . . . . . . . . . 16
4.3. Client-to-Server Masking . . . . . . . . . . . . . . . . 20 4.3. Client-to-Server Masking . . . . . . . . . . . . . . . . . 20
4.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 21 4.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 21
4.5. Control Frames . . . . . . . . . . . . . . . . . . . . . 22 4.5. Control Frames . . . . . . . . . . . . . . . . . . . . . . 22
4.5.1. Close . . . . . . . . . . . . . . . . . . . . . . . . 23 4.5.1. Close . . . . . . . . . . . . . . . . . . . . . . . . 23
4.5.2. Ping . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.5.2. Ping . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.5.3. Pong . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.5.3. Pong . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.6. Data Frames . . . . . . . . . . . . . . . . . . . . . . . 24 4.6. Data Frames . . . . . . . . . . . . . . . . . . . . . . . 24
4.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . 25 4.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 25 4.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 25
5. Opening Handshake . . . . . . . . . . . . . . . . . . . . . . 27 5. Opening Handshake . . . . . . . . . . . . . . . . . . . . . . 27
5.1. Client Requirements . . . . . . . . . . . . . . . . . . . 27 5.1. Client Requirements . . . . . . . . . . . . . . . . . . . 27
5.2. Server-side Requirements . . . . . . . . . . . . . . . . 32 5.2. Server-side Requirements . . . . . . . . . . . . . . . . . 32
5.2.1. Reading the Client's Opening Handshake . . . . . . . . 33 5.2.1. Reading the Client's Opening Handshake . . . . . . . . 32
5.2.2. Sending the Server's Opening Handshake . . . . . . . . 33 5.2.2. Sending the Server's Opening Handshake . . . . . . . . 33
6. Sending and Receiving Data . . . . . . . . . . . . . . . . . . 37 5.3. Collected ABNF for new header fields used in handshake . . 36
6.1. Sending Data . . . . . . . . . . . . . . . . . . . . . . 37 6. Sending and Receiving Data . . . . . . . . . . . . . . . . . . 38
6.2. Receiving Data . . . . . . . . . . . . . . . . . . . . . 37 6.1. Sending Data . . . . . . . . . . . . . . . . . . . . . . . 38
7. Closing the connection . . . . . . . . . . . . . . . . . . . . 39 6.2. Receiving Data . . . . . . . . . . . . . . . . . . . . . . 38
7.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 39 7. Closing the connection . . . . . . . . . . . . . . . . . . . . 40
7.1.1. Close the WebSocket Connection . . . . . . . . . . . . 39 7.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 40
7.1.2. Start the WebSocket Closing Handshake . . . . . . . . 39 7.1.1. Close the WebSocket Connection . . . . . . . . . . . . 40
7.1.3. The WebSocket Closing Handshake is Started . . . . . . 39 7.1.2. Start the WebSocket Closing Handshake . . . . . . . . 40
7.1.4. The WebSocket Connection is Closed . . . . . . . . . . 40 7.1.3. The WebSocket Closing Handshake is Started . . . . . . 40
7.1.5. The WebSocket Connection Close Code . . . . . . . . . 40 7.1.4. The WebSocket Connection is Closed . . . . . . . . . . 41
7.1.6. The WebSocket Connection Close Reason . . . . . . . . 40 7.1.5. The WebSocket Connection Close Code . . . . . . . . . 41
7.1.7. Fail the WebSocket Connection . . . . . . . . . . . . 41 7.1.6. The WebSocket Connection Close Reason . . . . . . . . 41
7.2. Abnormal Closures . . . . . . . . . . . . . . . . . . . . 41 7.1.7. Fail the WebSocket Connection . . . . . . . . . . . . 42
7.2.1. Client-Initiated Closure . . . . . . . . . . . . . . . 41 7.2. Abnormal Closures . . . . . . . . . . . . . . . . . . . . 42
7.2.2. Server-initiated closure . . . . . . . . . . . . . . . 42 7.2.1. Client-Initiated Closure . . . . . . . . . . . . . . . 42
7.3. Normal Closure of Connections . . . . . . . . . . . . . . 42 7.2.2. Server-initiated closure . . . . . . . . . . . . . . . 43
7.4. Status Codes . . . . . . . . . . . . . . . . . . . . . . 42 7.3. Normal Closure of Connections . . . . . . . . . . . . . . 43
7.4.1. Defined Status Codes . . . . . . . . . . . . . . . . . 42 7.4. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 43
7.4.2. Reserved Status Code Ranges . . . . . . . . . . . . . 43 7.4.1. Defined Status Codes . . . . . . . . . . . . . . . . . 43
8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 45 7.4.2. Reserved Status Code Ranges . . . . . . . . . . . . . 44
8.1. Handling Errors in UTF-8 Encoded Data . . . . . . . . . . 45 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 46
9. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 46 8.1. Handling Errors in UTF-8 Encoded Data . . . . . . . . . . 46
9.1. Negotiating Extensions . . . . . . . . . . . . . . . . . 46 9. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 47
9.2. Known Extensions . . . . . . . . . . . . . . . . . . . . 47 9.1. Negotiating Extensions . . . . . . . . . . . . . . . . . . 47
9.2.1. Compression . . . . . . . . . . . . . . . . . . . . . 47 9.2. Known Extensions . . . . . . . . . . . . . . . . . . . . . 48
10. Security Considerations . . . . . . . . . . . . . . . . . . . 49 10. Security Considerations . . . . . . . . . . . . . . . . . . . 49
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52
11.1. Registration of "ws:" Scheme . . . . . . . . . . . . . . 51 11.1. Registration of new URI Schemes . . . . . . . . . . . . . 52
11.2. Registration of "wss:" Scheme . . . . . . . . . . . . . . 52 11.1.1. Registration of "ws:" Scheme . . . . . . . . . . . . . 52
11.3. Registration of the "WebSocket" HTTP Upgrade Keyword . . 53 11.1.2. Registration of "wss:" Scheme . . . . . . . . . . . . 53
11.4. Sec-WebSocket-Key . . . . . . . . . . . . . . . . . . . . 53 11.2. Registration of the "WebSocket" HTTP Upgrade Keyword . . . 54
11.5. Sec-WebSocket-Extensions . . . . . . . . . . . . . . . . 54 11.3. Registration of new HTTP Header Fields . . . . . . . . . . 54
11.6. WebSocket Extension Name Registry . . . . . . . . . . . . 55 11.3.1. Sec-WebSocket-Key . . . . . . . . . . . . . . . . . . 54
11.7. Sec-WebSocket-Accept . . . . . . . . . . . . . . . . . . 56 11.3.2. Sec-WebSocket-Extensions . . . . . . . . . . . . . . . 55
11.8. Sec-WebSocket-Origin . . . . . . . . . . . . . . . . . . 56 11.3.3. Sec-WebSocket-Accept . . . . . . . . . . . . . . . . . 56
11.9. Sec-WebSocket-Protocol . . . . . . . . . . . . . . . . . 57 11.3.4. Sec-WebSocket-Protocol . . . . . . . . . . . . . . . . 56
11.10. WebSocket Subprotocol Name Registry . . . . . . . . . . . 57 11.3.5. Sec-WebSocket-Version . . . . . . . . . . . . . . . . 57
11.11. Sec-WebSocket-Version . . . . . . . . . . . . . . . . . . 58 11.4. WebSocket Extension Name Registry . . . . . . . . . . . . 58
11.12. WebSocket Version Number Registry . . . . . . . . . . . . 59 11.5. WebSocket Subprotocol Name Registry . . . . . . . . . . . 59
11.13. WebSocket Close Code Number Registry . . . . . . . . . . 60 11.6. WebSocket Version Number Registry . . . . . . . . . . . . 59
11.14. WebSocket Opcode Registry . . . . . . . . . . . . . . . . 61 11.7. WebSocket Close Code Number Registry . . . . . . . . . . . 60
11.15. WebSocket Framing Header Bits Registry . . . . . . . . . 62 11.8. WebSocket Opcode Registry . . . . . . . . . . . . . . . . 62
12. Using the WebSocket protocol from Other Specifications . . . . 63 11.9. WebSocket Framing Header Bits Registry . . . . . . . . . . 63
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 64 12. Using the WebSocket protocol from Other Specifications . . . . 64
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 65
14.1. Normative References . . . . . . . . . . . . . . . . . . 65 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66
14.2. Informative References . . . . . . . . . . . . . . . . . 66 14.1. Normative References . . . . . . . . . . . . . . . . . . . 66
14.2. Informative References . . . . . . . . . . . . . . . . . . 67
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 68
1. Introduction 1. Introduction
1.1. Background 1.1. Background
_This section is non-normative._ _This section is non-normative._
Historically, creating Web applications that need bidirectional Historically, creating Web applications that need bidirectional
communication between a client and a server (e.g., instant messaging communication between a client and a server (e.g., instant messaging
skipping to change at page 5, line 10 skipping to change at page 5, line 10
The protocol has two parts: a handshake, and then the data transfer. The protocol has two parts: a handshake, and then the data transfer.
The handshake from the client looks as follows: The handshake from the client looks as follows:
GET /chat HTTP/1.1 GET /chat HTTP/1.1
Host: server.example.com Host: server.example.com
Upgrade: websocket Upgrade: websocket
Connection: Upgrade Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Origin: http://example.com Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 8 Sec-WebSocket-Version: 8
The handshake from the server looks as follows: The handshake from the server looks as follows:
HTTP/1.1 101 Switching Protocols HTTP/1.1 101 Switching Protocols
Upgrade: websocket Upgrade: websocket
Connection: Upgrade Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat Sec-WebSocket-Protocol: chat
The leading line from the client follows the Request-Line format. The leading line from the client follows the Request-Line format.
The leading line from the server follows the Status-Line format. The The leading line from the server follows the Status-Line format. The
Request-Line and Status-Line productions are defined in [RFC2616]. Request-Line and Status-Line productions are defined in [RFC2616].
After the leading line in both cases come an unordered set of header After the leading line in both cases come an unordered set of header
fields. The meaning of these header fields is specified in Section 5 fields. The meaning of these header fields is specified in Section 5
of this document. Additional header fields may also be present, such of this document. Additional header fields may also be present, such
as cookies [RFC6265] required to identify the user. The format and as cookies [RFC6265]. The format and parsing of headers is as
parsing of headers is as defined in [RFC2616]. defined in [RFC2616].
Once the client and server have both sent their handshakes, and if Once the client and server have both sent their handshakes, and if
the handshake was successful, then the data transfer part starts. the handshake was successful, then the data transfer part starts.
This is a two-way communication channel where each side can, This is a two-way communication channel where each side can,
independently from the other, send data at will. independently from the other, send data at will.
Clients and servers, after a successful handshake, transfer data back Clients and servers, after a successful handshake, transfer data back
and forth in conceptual units referred to in this specification as and forth in conceptual units referred to in this specification as
"messages". A message is a complete unit of data at an application "messages". A message is a complete unit of data at an application
level, with the expectation that many or most applications level, with the expectation that many or most applications
skipping to change at page 6, line 31 skipping to change at page 6, line 31
server-side software and intermediaries, so that a single port can be server-side software and intermediaries, so that a single port can be
used by both HTTP clients talking to that server and WebSocket used by both HTTP clients talking to that server and WebSocket
clients talking to that server. To this end, the WebSocket client's clients talking to that server. To this end, the WebSocket client's
handshake is an HTTP Upgrade request: handshake is an HTTP Upgrade request:
GET /chat HTTP/1.1 GET /chat HTTP/1.1
Host: server.example.com Host: server.example.com
Upgrade: websocket Upgrade: websocket
Connection: Upgrade Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Origin: http://example.com Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 8 Sec-WebSocket-Version: 8
In compliance with [RFC2616], header fields in the handshake may be In compliance with [RFC2616], header fields in the handshake may be
sent by the client in any order, so the order in which different sent by the client in any order, so the order in which different
header fields are received is not significant. header fields are received is not significant.
The "Request-URI" of the GET method [RFC2616] is used to identify the The "Request-URI" of the GET method [RFC2616] is used to identify the
endpoint of the WebSocket connection, both to allow multiple domains endpoint of the WebSocket connection, both to allow multiple domains
to be served from one IP address and to allow multiple WebSocket to be served from one IP address and to allow multiple WebSocket
endpoints to be served by a single server. endpoints to be served by a single server.
The client includes the hostname in the Host header of its handshake The client includes the hostname in the Host header field of its
as per [RFC2616], so that both the client and the server can verify handshake as per [RFC2616], so that both the client and the server
that they agree on which host is in use. can verify that they agree on which host is in use.
Additional headers are used to select options in the WebSocket Additional header fields are used to select options in the WebSocket
protocol. Options available in this version are the subprotocol protocol. Options available in this version are the subprotocol
selector, |Sec-WebSocket-Protocol|, and |Cookie|, which can used for selector, |Sec-WebSocket-Protocol|. The |Sec-WebSocket-Protocol|
sending cookies to the server (e.g. as an authentication mechanism). request-header field can be used to indicate what subprotocols
The |Sec-WebSocket-Protocol| request-header field can be used to (application-level protocols layered over the WebSocket protocol) are
indicate what subprotocols (application-level protocols layered over acceptable to the client. The server selects one of the acceptable
the WebSocket protocol) are acceptable to the client. The server protocols and echoes that value in its handshake to indicate that it
selects one of the acceptable protocols and echoes that value in its has selected that protocol.
handshake to indicate that it has selected that protocol.
Sec-WebSocket-Protocol: chat Sec-WebSocket-Protocol: chat
The |Sec-WebSocket-Origin| header is used to protect against The |Origin| header field [I-D.ietf-websec-origin] is used to protect
unauthorized cross-origin use of a WebSocket server by scripts using against unauthorized cross-origin use of a WebSocket server by
the |WebSocket| API in a Web browser. The server is informed of the scripts using the |WebSocket| API in a Web browser. The server is
script origin generating the WebSocket connection request. If the informed of the script origin generating the WebSocket connection
server does not wish to accept connections from this origin, it can request. If the server does not wish to accept connections from this
choose to reject the connection by sending an appropriate HTTP error origin, it can choose to reject the connection by sending an
code. This header is sent by browser clients, for non-browser appropriate HTTP error code. This header field is sent by browser
clients this header may be sent if it makes sense in the context of clients, for non-browser clients this header field may be sent if it
those clients. makes sense in the context of those clients.
NOTE: It is worth noting that for the attack cases this header
protects against, the untrusted party is typically the author of a
JavaScript application that is executing in the context of the
client. The client itself can contact the server and via the
mechanism of the |Sec-WebSocket-Origin| header, determine whether to
extend those communication privileges to the JavaScript application.
A JavaScript application cannot set a header starting with "Sec-" via
XMLHttpRequest. The intent is not to prevent non-browsers from
establishing connections, but rather to ensure that browsers under
the control of potentially malicious JavaScript cannot fake a
WebSocket handshake.
Finally, the server has to prove to the client that it received the Finally, the server has to prove to the client that it received the
client's WebSocket handshake, so that the server doesn't accept client's WebSocket handshake, so that the server doesn't accept
connections that are not WebSocket connections. This prevents an connections that are not WebSocket connections. This prevents an
attacker from tricking a WebSocket server by sending it carefully- attacker from tricking a WebSocket server by sending it carefully-
crafted packets using |XMLHttpRequest| or a |form| submission. crafted packets using |XMLHttpRequest| or a |form| submission.
To prove that the handshake was received, the server has to take two To prove that the handshake was received, the server has to take two
pieces of information and combine them to form a response. The first pieces of information and combine them to form a response. The first
piece of information comes from the |Sec-WebSocket-Key| header in the piece of information comes from the |Sec-WebSocket-Key| header field
client handshake: in the client handshake:
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
For this header, the server has to take the value (as present in the For this header field, the server has to take the value (as present
header, e.g. the base64-encoded [RFC4648] version minus any leading in the header field, e.g. the base64-encoded [RFC4648] version minus
and trailing whitespace), and concatenate this with the GUID any leading and trailing whitespace), and concatenate this with the
"258EAFA5-E914-47DA-95CA-C5AB0DC85B11" in string form, which is Globally Unique Identifier (GUID, [RFC4122]) "258EAFA5-E914-47DA-
unlikely to be used by network endpoints that do not understand the 95CA-C5AB0DC85B11" in string form, which is unlikely to be used by
WebSocket protocol. A SHA-1 hash (160 bits), base64-encoded (see network endpoints that do not understand the WebSocket protocol. A
Section 4 of [RFC4648]), of this concatenation is then returned in SHA-1 hash (160 bits), base64-encoded (see Section 4 of [RFC4648]),
the server's handshake [FIPS.180-2.2002]. of this concatenation is then returned in the server's handshake
[FIPS.180-2.2002].
Concretely, if as in the example above, header |Sec-WebSocket-Key| Concretely, if as in the example above, |Sec-WebSocket-Key| header
had the value "dGhlIHNhbXBsZSBub25jZQ==", the server would field had the value "dGhlIHNhbXBsZSBub25jZQ==", the server would
concatenate the string "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" to form concatenate the string "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" to form
the string "dGhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CA- the string "dGhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CA-
C5AB0DC85B11". The server would then take the SHA-1 hash of this, C5AB0DC85B11". The server would then take the SHA-1 hash of this,
giving the value 0xb3 0x7a 0x4f 0x2c 0xc0 0x62 0x4f 0x16 0x90 0xf6 giving the value 0xb3 0x7a 0x4f 0x2c 0xc0 0x62 0x4f 0x16 0x90 0xf6
0x46 0x06 0xcf 0x38 0x59 0x45 0xb2 0xbe 0xc4 0xea. This value is 0x46 0x06 0xcf 0x38 0x59 0x45 0xb2 0xbe 0xc4 0xea. This value is
then base64-encoded (see Section 4 of [RFC4648]), to give the value then base64-encoded (see Section 4 of [RFC4648]), to give the value
"s3pPLMBiTxaQ9kYGzzhZRbK+xOo=". This value would then be echoed in "s3pPLMBiTxaQ9kYGzzhZRbK+xOo=". This value would then be echoed in
the header |Sec-WebSocket-Accept|. the |Sec-WebSocket-Accept| header field.
The handshake from the server is much simpler than the client The handshake from the server is much simpler than the client
handshake. The first line is an HTTP Status-Line, with the status handshake. The first line is an HTTP Status-Line, with the status
code 101: code 101:
HTTP/1.1 101 Switching Protocols HTTP/1.1 101 Switching Protocols
Any status code other than 101 indicates that the WebSocket handshake Any status code other than 101 indicates that the WebSocket handshake
has not completed, and that the semantics of HTTP still apply. The has not completed, and that the semantics of HTTP still apply. The
headers follow the status code. headers follow the status code.
The |Connection| and |Upgrade| headers complete the HTTP Upgrade. The |Connection| and |Upgrade| header fields complete the HTTP
The |Sec-WebSocket-Accept| header indicates whether the server is Upgrade. The |Sec-WebSocket-Accept| header field indicates whether
willing to accept the connection. If present, this header must the server is willing to accept the connection. If present, this
include a hash of the client's nonce sent in |Sec-WebSocket-Key| header field must include a hash of the client's nonce sent in |Sec-
along with a predefined GUID. Any other value must not be WebSocket-Key| along with a predefined GUID. Any other value must
interpreted as an acceptance of the connection by the server. not be interpreted as an acceptance of the connection by the server.
HTTP/1.1 101 Switching Protocols HTTP/1.1 101 Switching Protocols
Upgrade: websocket Upgrade: websocket
Connection: Upgrade Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
These fields are checked by the Web browser when it is acting as a These fields are checked by the Web browser when it is acting as a
|WebSocket| client for scripted pages. If the |Sec-WebSocket-Accept| |WebSocket| client for scripted pages. If the |Sec-WebSocket-Accept|
value does not match the expected value, or if the header is missing, value does not match the expected value, or if the header field is
or if the HTTP status code is not 101, the connection will not be missing, or if the HTTP status code is not 101, the connection will
established and WebSocket frames will not be sent. not be established and WebSocket frames will not be sent.
Option fields can also be included. In this version of the protocol, Option fields can also be included. In this version of the protocol,
the main option field is |Sec-WebSocket-Protocol|, which indicates the main option field is |Sec-WebSocket-Protocol|, which indicates
the subprotocol that the server has selected. Web browsers verify the subprotocol that the server has selected. Web browsers verify
that the server included one of the values as was specified in the that the server included one of the values as was specified in the
WebSocket client's handshake. A server that speaks multiple WebSocket client's handshake. A server that speaks multiple
subprotocols has to make sure it selects one based on the client's subprotocols has to make sure it selects one based on the client's
handshake and specifies it in its handshake. handshake and specifies it in its handshake.
Sec-WebSocket-Protocol: chat Sec-WebSocket-Protocol: chat
The server can also set cookie-related option fields to _set_ The server can also set cookie-related option fields to _set_
cookies, as in HTTP. cookies, as described in [RFC6265].
1.4. Closing Handshake 1.4. Closing Handshake
_This section is non-normative._ _This section is non-normative._
The closing handshake is far simpler than the opening handshake. The closing handshake is far simpler than the opening handshake.
Either peer can send a control frame with data containing a specified Either peer can send a control frame with data containing a specified
control sequence to begin the closing handshake (detailed in control sequence to begin the closing handshake (detailed in
Section 4.5.1). Upon receiving such a frame, the other peer sends a Section 4.5.1). Upon receiving such a frame, the other peer sends a
skipping to change at page 12, line 4 skipping to change at page 11, line 41
set of hosts for WebSocket connections separate from the HTTP servers set of hosts for WebSocket connections separate from the HTTP servers
is probably easier to manage. At the time of writing of this is probably easier to manage. At the time of writing of this
specification, it should be noted that connections on port 80 and 443 specification, it should be noted that connections on port 80 and 443
have significantly different success rates, with connections on port have significantly different success rates, with connections on port
443 being significantly more likely to succeed, though this may 443 being significantly more likely to succeed, though this may
change with time. change with time.
1.9. Subprotocols Using the WebSocket protocol 1.9. Subprotocols Using the WebSocket protocol
_This section is non-normative._ _This section is non-normative._
The client can request that the server use a specific subprotocol by The client can request that the server use a specific subprotocol by
including the |Sec-WebSocket-Protocol| field in its handshake. If it including the |Sec-WebSocket-Protocol| field in its handshake. If it
is specified, the server needs to include the same field and one of is specified, the server needs to include the same field and one of
the selected subprotocol values in its response for the connection to the selected subprotocol values in its response for the connection to
be established. be established.
These subprotocol names should be registered as per Section 11.10. These subprotocol names should be registered as per Section 11.5. To
To avoid potential collisions, it is recommended to use names that avoid potential collisions, it is recommended to use names that
contain the ASCII version of the domain name of the subprotocol's contain the ASCII version of the domain name of the subprotocol's
originator. For example, if Example Corporation were to create a originator. For example, if Example Corporation were to create a
Chat subprotocol to be implemented by many servers around the Web, Chat subprotocol to be implemented by many servers around the Web,
they could name it "chat.example.com". If the Example Organization they could name it "chat.example.com". If the Example Organization
called their competing subprotocol "chat.example.org", then the two called their competing subprotocol "chat.example.org", then the two
subprotocols could be implemented by servers simultaneously, with the subprotocols could be implemented by servers simultaneously, with the
server dynamically selecting which subprotocol to use based on the server dynamically selecting which subprotocol to use based on the
value sent by the client. value sent by the client.
Subprotocols can be versioned in backwards-incompatible ways by Subprotocols can be versioned in backwards-incompatible ways by
skipping to change at page 13, line 26 skipping to change at page 13, line 26
"strip any leading space characters" or "return false and abort these "strip any leading space characters" or "return false and abort these
steps") are to be interpreted with the meaning of the key word steps") are to be interpreted with the meaning of the key word
("must", "should", "may", etc) used in introducing the algorithm. ("must", "should", "may", etc) used in introducing the algorithm.
Conformance requirements phrased as algorithms or specific steps MAY Conformance requirements phrased as algorithms or specific steps MAY
be implemented in any manner, so long as the end result is be implemented in any manner, so long as the end result is
equivalent. (In particular, the algorithms defined in this equivalent. (In particular, the algorithms defined in this
specification are intended to be easy to follow, and not intended to specification are intended to be easy to follow, and not intended to
be performant.) be performant.)
Implementations MAY impose implementation-specific limits on
otherwise unconstrained inputs, e.g. to prevent denial of service
attacks, to guard against running out of memory, or to work around
platform-specific limitations.
The conformance classes defined by this specification are clients and The conformance classes defined by this specification are clients and
servers. servers.
2.1. Terminology 2.1. Terminology
_ASCII_ shall mean the character-encoding scheme defined in _ASCII_ shall mean the character-encoding scheme defined in
[ANSI.X3-4.1986]. [ANSI.X3-4.1986].
This document makes reference to UTF-8 values and uses UTF-8 This document makes reference to UTF-8 values and uses UTF-8
notational formats as defined in STD 63 [RFC3629]. notational formats as defined in STD 63 [RFC3629].
Key Terms such as named algorithms or definitions are indicated like Key Terms such as named algorithms or definitions are indicated like
_this_. _this_.
Names of headers or variables are indicated like |this|. Names of header fields or variables are indicated like |this|.
Variable values are indicated like /this/. Variable values are indicated like /this/.
This document references the procedure to _Fail the WebSocket
Connection_. This procedure is defined in Section 7.1.7.
_Converting a string to ASCII lowercase_ means replacing all _Converting a string to ASCII lowercase_ means replacing all
characters in the range U+0041 to U+005A (i.e. LATIN CAPITAL LETTER characters in the range U+0041 to U+005A (i.e. LATIN CAPITAL LETTER
A to LATIN CAPITAL LETTER Z) with the corresponding characters in the A to LATIN CAPITAL LETTER Z) with the corresponding characters in the
range U+0061 to U+007A (i.e. LATIN SMALL LETTER A to LATIN SMALL range U+0061 to U+007A (i.e. LATIN SMALL LETTER A to LATIN SMALL
LETTER Z). LETTER Z).
Comparing two strings in an _ASCII case-insensitive_ manner means Comparing two strings in an _ASCII case-insensitive_ manner means
comparing them exactly, code point for code point, except that the comparing them exactly, code point for code point, except that the
characters in the range U+0041 to U+005A (i.e. LATIN CAPITAL LETTER characters in the range U+0041 to U+005A (i.e. LATIN CAPITAL LETTER
A to LATIN CAPITAL LETTER Z) and the corresponding characters in the A to LATIN CAPITAL LETTER Z) and the corresponding characters in the
skipping to change at page 20, line 34 skipping to change at page 20, line 34
[RFC4086] discusses what entails a suitable source of entropy for [RFC4086] discusses what entails a suitable source of entropy for
security-sensitive applications. security-sensitive applications.
The masking does not affect the length of the payload data. To The masking does not affect the length of the payload data. To
convert masked data into unmasked data, or vice versa, the following convert masked data into unmasked data, or vice versa, the following
algorithm is applied. The same algorithm applies regardless of the algorithm is applied. The same algorithm applies regardless of the
direction of the translation - e.g. the same steps are applied to direction of the translation - e.g. the same steps are applied to
mask the data as to unmask the data. mask the data as to unmask the data.
Octet i of the transformed data ("transformed-octet-i") is the XOR of Octet i of the transformed data ("transformed-octet-i") is the XOR of
octet i of the original data ("original-octet-i") with octet i modulo octet i of the original data ("original-octet-i") with octet at index
4 of the masking key ("masking-key-octet-j"): i modulo 4 of the masking key ("masking-key-octet-j"):
j = i MOD 4 j = i MOD 4
transformed-octet-i = original-octet-i XOR masking-key-octet-j transformed-octet-i = original-octet-i XOR masking-key-octet-j
When preparing a masked frame, the client MUST pick a fresh masking When preparing a masked frame, the client MUST pick a fresh masking
key from the set of allowed 32-bit values. The masking key must be key from the set of allowed 32-bit values. The masking key must be
unpredictable. The unpredictability of the masking key is essential unpredictable. The unpredictability of the masking key is essential
to prevent the author of malicious applications from selecting the to prevent the author of malicious applications from selecting the
bytes that appear on the wire. bytes that appear on the wire.
skipping to change at page 21, line 38 skipping to change at page 21, line 38
with the FIN bit clear and the opcode set to 0, and terminated by with the FIN bit clear and the opcode set to 0, and terminated by
a single frame with the FIN bit set and an opcode of 0. A a single frame with the FIN bit set and an opcode of 0. A
fragmented message is conceptually equivalent to a single larger fragmented message is conceptually equivalent to a single larger
message whose payload is equal to the concatenation of the message whose payload is equal to the concatenation of the
payloads of the fragments in order, however in the presence of payloads of the fragments in order, however in the presence of
extensions this may not hold true as the extension defines the extensions this may not hold true as the extension defines the
interpretation of the extension data present. For instance, interpretation of the extension data present. For instance,
extension data may only be present at the beginning of the first extension data may only be present at the beginning of the first
fragment and apply to subsequent fragments, or there may be fragment and apply to subsequent fragments, or there may be
extension data present in each of the fragments that applies only extension data present in each of the fragments that applies only
to that particular fragment. Setting aside the issue of to that particular fragment. In absence of extension data, the
extensions, the following example demonstrates how fragmentation following example demonstrates how fragmentation works.
works.
EXAMPLE: For a text message sent as three fragments, the first EXAMPLE: For a text message sent as three fragments, the first
fragment would have an opcode of 0x1 and a FIN bit clear, the fragment would have an opcode of 0x1 and a FIN bit clear, the
second fragment would have an opcode of 0x0 and a FIN bit clear, second fragment would have an opcode of 0x0 and a FIN bit clear,
and the third fragment would have an opcode of 0x0 and a FIN bit and the third fragment would have an opcode of 0x0 and a FIN bit
that is set. that is set.
o Control frames MAY be injected in the middle of a fragmented o Control frames MAY be injected in the middle of a fragmented
message. Control frames themselves MUST NOT be fragmented. message. Control frames themselves MUST NOT be fragmented.
skipping to change at page 23, line 21 skipping to change at page 23, line 21
the frame) that indicates a reason for closing, such as an endpoint the frame) that indicates a reason for closing, such as an endpoint
shutting down, an endpoint having received a frame too large, or an shutting down, an endpoint having received a frame too large, or an
endpoint having received a frame that does not conform to the format endpoint having received a frame that does not conform to the format
expected by the other endpoint. If there is a body, the first two expected by the other endpoint. If there is a body, the first two
bytes of the body MUST be a 2-byte unsigned integer (in network byte bytes of the body MUST be a 2-byte unsigned integer (in network byte
order) representing a status code with value /code/ defined in order) representing a status code with value /code/ defined in
Section 7.4. Following the 2-byte integer the body MAY contain UTF-8 Section 7.4. Following the 2-byte integer the body MAY contain UTF-8
encoded data with value /reason/, the interpretation of which is not encoded data with value /reason/, the interpretation of which is not
defined by this specification. This data is not necessarily human defined by this specification. This data is not necessarily human
readable, but may be useful for debugging or passing information readable, but may be useful for debugging or passing information
relevant to the script that opened the connection. relevant to the script that opened the connection. As the data is
not guaranteed to be human readable, clients MUST NOT show it to end
users.
Close frames sent from client to server must be masked as per Close frames sent from client to server must be masked as per
Section 4.3. Section 4.3.
The application MUST NOT send any more data frames after sending a The application MUST NOT send any more data frames after sending a
close frame. close frame.
If an endpoint receives a Close frame and that endpoint did not If an endpoint receives a Close frame and that endpoint did not
previously send a Close frame, the endpoint MUST send a Close frame previously send a Close frame, the endpoint MUST send a Close frame
in response. It SHOULD do so as soon as is practical. An endpoint in response. It SHOULD do so as soon as is practical. An endpoint
skipping to change at page 24, line 46 skipping to change at page 24, line 46
expected. expected.
4.6. Data Frames 4.6. Data Frames
Data frames (e.g. non-control frames) are identified by opcodes where Data frames (e.g. non-control frames) are identified by opcodes where
the most significant bit of the opcode is 0. Currently defined the most significant bit of the opcode is 0. Currently defined
opcodes for data frames include 0x1 (Text), 0x2 (Binary). Opcodes opcodes for data frames include 0x1 (Text), 0x2 (Binary). Opcodes
0x3-0x7 are reserved for further non-control frames yet to be 0x3-0x7 are reserved for further non-control frames yet to be
defined. defined.
Data frames carry application-layer or extension-layer data. The Data frames carry application-layer and/or extension-layer data. The
opcode determines the interpretation of the data: opcode determines the interpretation of the data:
Text Text
The payload data is text data encoded as UTF-8. The payload data is text data encoded as UTF-8. Note that a
particular text frame might include a partial UTF-8 sequence,
however the whole message MUST contain valid UTF-8.
Binary Binary
The payload data is arbitrary binary data whose interpretation is The payload data is arbitrary binary data whose interpretation is
solely up to the application layer. solely up to the application layer.
4.7. Examples 4.7. Examples
_This section is non-normative._ _This section is non-normative._
skipping to change at page 25, line 29 skipping to change at page 25, line 30
* 0x81 0x85 0x37 0xfa 0x21 0x3d 0x7f 0x9f 0x4d 0x51 0x58 * 0x81 0x85 0x37 0xfa 0x21 0x3d 0x7f 0x9f 0x4d 0x51 0x58
(contains "Hello") (contains "Hello")
o A fragmented unmasked text message o A fragmented unmasked text message
* 0x01 0x03 0x48 0x65 0x6c (contains "Hel") * 0x01 0x03 0x48 0x65 0x6c (contains "Hel")
* 0x80 0x02 0x6c 0x6f (contains "lo") * 0x80 0x02 0x6c 0x6f (contains "lo")
o Ping request and response o Unmasked Ping request and masked Ping response
* 0x89 0x05 0x48 0x65 0x6c 0x6c 0x6f (contains a body of "Hello", * 0x89 0x05 0x48 0x65 0x6c 0x6c 0x6f (contains a body of "Hello",
but the contents of the body are arbitrary) but the contents of the body are arbitrary)
* 0x8a 0x05 0x48 0x65 0x6c 0x6c 0x6f (contains a body of "Hello", * 0x8a 0x85 0x37 0xfa 0x21 0x3d 0x7f 0x9f 0x4d 0x51 0x58
matching the body of the ping) (contains a body of "Hello", matching the body of the ping)
o 256 bytes binary message in a single unmasked frame o 256 bytes binary message in a single unmasked frame
* 0x82 0x7E 0x0100 [256 bytes of binary data] * 0x82 0x7E 0x0100 [256 bytes of binary data]
o 64KiB binary message in a single unmasked frame o 64KiB binary message in a single unmasked frame
* 0x82 0x7F 0x0000000000010000 [65536 bytes of binary data] * 0x82 0x7F 0x0000000000010000 [65536 bytes of binary data]
4.8. Extensibility 4.8. Extensibility
skipping to change at page 29, line 42 skipping to change at page 29, line 42
all further communication on this channel MUST run through the all further communication on this channel MUST run through the
encrypted tunnel. [RFC5246] encrypted tunnel. [RFC5246]
Clients MUST use the Server Name Indication extension in the TLS Clients MUST use the Server Name Indication extension in the TLS
handshake. [RFC6066] handshake. [RFC6066]
Once a connection to the server has been established (including a Once a connection to the server has been established (including a
connection via a proxy or over a TLS-encrypted tunnel), the client connection via a proxy or over a TLS-encrypted tunnel), the client
MUST send an opening handshake to the server. The handshake consists MUST send an opening handshake to the server. The handshake consists
of an HTTP upgrade request, along with a list of required and of an HTTP upgrade request, along with a list of required and
optional headers. The requirements for this handshake are as optional header fields. The requirements for this handshake are as
follows. follows.
1. The handshake MUST be a valid HTTP request as specified by 1. The handshake MUST be a valid HTTP request as specified by
[RFC2616]. [RFC2616].
2. The Method of the request MUST be GET and the HTTP version MUST 2. The Method of the request MUST be GET and the HTTP version MUST
be at least 1.1. be at least 1.1.
For example, if the WebSocket URI is "ws://example.com/chat", For example, if the WebSocket URI is "ws://example.com/chat",
The first line sent should be "GET /chat HTTP/1.1" The first line sent should be "GET /chat HTTP/1.1"
3. The request MUST contain a "Request-URI" as part of the GET 3. The "Request-URI" part of the request MUST match the /resource
method. This MUST match the /resource name/ Section 3 (a name/ Section 3 (a relative URI), or be an absolute http/https
relative URI), or be an absolute URI that, when parsed, has a URI that, when parsed, has a /resource name/, /host/ and /port/
matching /resource name/ as well as matching /host/, /port/, and that match the corresponding ws/wss URI.
appropriate scheme (ws or wss).
4. The request MUST contain a "Host" header whose value is equal to 4. The request MUST contain a "Host" header field whose value is
/host/. equal to /host/.
5. The request MUST contain an "Upgrade" header whose value is 5. The request MUST contain an "Upgrade" header field whose value
equal to "websocket". is equal to "websocket".
6. The request MUST contain a "Connection" header whose value MUST 6. The request MUST contain a "Connection" header field whose value
include the "Upgrade" token. MUST include the "Upgrade" token.
7. The request MUST include a header with the name "Sec-WebSocket- 7. The request MUST include a header field with the name "Sec-
Key". The value of this header MUST be a nonce consisting of a WebSocket-Key". The value of this header field MUST be a nonce
randomly selected 16-byte value that has been base64-encoded consisting of a randomly selected 16-byte value that has been
(see Section 4 of [RFC4648]). The nonce MUST be selected base64-encoded (see Section 4 of [RFC4648]). The nonce MUST be
randomly for each connection. selected randomly for each connection.
NOTE: As an example, if the randomly selected value was the NOTE: As an example, if the randomly selected value was the
sequence of bytes 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 sequence of bytes 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09
0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10, the value of the header 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10, the value of the header
would be "AQIDBAUGBwgJCgsMDQ4PEC==" field would be "AQIDBAUGBwgJCgsMDQ4PEC=="
8. The request MUST include a header with the name "Sec-WebSocket- 8. The request MUST include a header field with the name "Origin"
Origin" if the request is coming from a browser client. If the [I-D.ietf-websec-origin] if the request is coming from a browser
connection is from a non-browser client, the request MAY include client. If the connection is from a non-browser client, the
this header if the semantics of that client match the use-case request MAY include this header field if the semantics of that
described here for browser clients. The value of this header client match the use-case described here for browser clients.
MUST be the ASCII serialization of origin of the context in The value of this header field is the ASCII serialization of
which the code establishing the connection is running, and MUST origin of the context in which the code establishing the
be lower-case. The value MUST NOT contain letters in the range connection is running. See [I-D.ietf-websec-origin] for the
U+0041 to U+005A (i.e. LATIN CAPITAL LETTER A to LATIN CAPITAL details of how this header field value is constructed.
LETTER Z) [I-D.ietf-websec-origin]. The ABNF is as defined in
Section 6.1 of [I-D.ietf-websec-origin].
As an example, if code is running on www.example.com attempting As an example, if code is running on www.example.com attempting
to establish a connection to ww2.example.com, the value of the to establish a connection to ww2.example.com, the value of the
header would be "http://www.example.com". header field would be "http://www.example.com".
9. The request MUST include a header with the name "Sec-WebSocket- 9. The request MUST include a header field with the name "Sec-
Version". The value of this header MUST be 8. _Note: Although a WebSocket-Version". The value of this header field MUST be 8.
draft -09 was published, as -09 was comprised of editorial _Note: Although drafts -09, -10 and -11 were published, as they
changes and not changes to the wire protocol, 9 was not used as were mostly comprised of editorial changes and clarifications
a valid value for Sec-WebSocket-Version. This value was and not changes to the wire protocol, values 9, 10 and 11 were
reserved in the IANA registry but was not and will not be used. not used as valid values for Sec-WebSocket-Version. These
If subsequent changes to the wire protocol are necessary, 9 will values were reserved in the IANA registry but were not and will
be skipped to prevent confusion with the draft 9 protocol._ not be used. If subsequent changes to the wire protocol are
necessary, values 9, 10 and 11 will be skipped to prevent
confusion with the draft 9/10/11 protocol._
10. The request MAY include a header with the name "Sec-WebSocket- 10. The request MAY include a header field with the name "Sec-
Protocol". If present, this value indicates one or more comma WebSocket-Protocol". If present, this value indicates one or
separated subprotocol the client wishes to speak, ordered by more comma separated subprotocol the client wishes to speak,
preference. The elements that comprise this value MUST be non- ordered by preference. The elements that comprise this value
empty strings with characters in the range U+0021 to U+007E not MUST be non-empty strings with characters in the range U+0021 to
including separator characters as defined in [RFC2616], and MUST U+007E not including separator characters as defined in
all be unique strings. The ABNF for the value of this header is [RFC2616], and MUST all be unique strings. The ABNF for the
1#token, where the definitions of constructs and rules are as value of this header field is 1#token, where the definitions of
given in [RFC2616]. constructs and rules are as given in [RFC2616].
11. The request MAY include a header with the name "Sec-WebSocket- 11. The request MAY include a header field with the name "Sec-
Extensions". If present, this value indicates the protocol- WebSocket-Extensions". If present, this value indicates the
level extension(s) the client wishes to speak. The protocol-level extension(s) the client wishes to speak. The
interpretation and format of this header is described in interpretation and format of this header field is described in
Section 9.1. Section 9.1.
12. The request MAY include headers associated with sending cookies, 12. The request MAY include any other header fields, for example
as defined by the appropriate specifications [RFC6265]. These cookies [RFC6265].
headers are referred to as _Headers to Send Appropriate
Cookies_.
Once the client's opening handshake has been sent, the client MUST Once the client's opening handshake has been sent, the client MUST
wait for a response from the server before sending any further data. wait for a response from the server before sending any further data.
The client MUST validate the server's response as follows: The client MUST validate the server's response as follows:
1. If the status code received from the server is not 101, the 1. If the status code received from the server is not 101, the
client handles the response per HTTP procedures. Otherwise, client handles the response per HTTP procedures. Otherwise,
proceed as follows. proceed as follows.
2. If the response lacks an "Upgrade" header or the "Upgrade" header 2. If the response lacks an "Upgrade" header field or the "Upgrade"
contains a value that is not an ASCII case-insensitive match for header field contains a value that is not an ASCII case-
the value "websocket", the client MUST _Fail the WebSocket insensitive match for the value "websocket", the client MUST
Connection _. _Fail the WebSocket Connection _.
3. If the response lacks a "Connection" header or the "Connection" 3. If the response lacks a "Connection" header field or the
header contains a value that is not an ASCII case-insensitive "Connection" header field contains a value that is not an ASCII
match for the value "Upgrade", the client MUST _Fail the case-insensitive match for the value "Upgrade", the client MUST
WebSocket Connection_. _Fail the WebSocket Connection_.
4. If the response lacks a "Sec-WebSocket-Accept" header or the 4. If the response lacks a "Sec-WebSocket-Accept" header field or
"Sec-WebSocket-Accept" contains a value other than the base64- the "Sec-WebSocket-Accept" contains a value other than the
encoded SHA-1 of the concatenation of the "Sec-WebSocket-Key" (as base64-encoded SHA-1 of the concatenation of the "Sec-WebSocket-
a string, not base64-decoded) with the string "258EAFA5-E914- Key" (as a string, not base64-decoded) with the string "258EAFA5-
47DA-95CA-C5AB0DC85B11", but ignoring any leading and trailing E914-47DA-95CA-C5AB0DC85B11", but ignoring any leading and
whitespace, the client MUST _Fail the WebSocket Connection_ trailing whitespace, the client MUST _Fail the WebSocket
Connection_
5. If the response includes a "Sec-WebSocket-Extensions" header, and 5. If the response includes a "Sec-WebSocket-Extensions" header
this header indicates the use of an extension that was not field, and this header field indicates the use of an extension
present in the client' handshake (the server has indicated an that was not present in the client' handshake (the server has
extension not requested by the client), the client MUST _Fail the indicated an extension not requested by the client), the client
WebSocket Connection_. (The parsing of this header to determine MUST _Fail the WebSocket Connection_. (The parsing of this
which extensions are requested is discussed in Section 9.1.) header field to determine which extensions are requested is
discussed in Section 9.1.)
If the server's response does not conform to the requirements for the If the server's response does not conform to the requirements for the
server's handshake as defined in this section and in Section 5.2.2, server's handshake as defined in this section and in Section 5.2.2,
the client MUST _Fail the WebSocket Connection_. the client MUST _Fail the WebSocket Connection_.
If the server's response is validated as provided for above, it is If the server's response is validated as provided for above, it is
said that _The WebSocket Connection is Established_ and that the said that _The WebSocket Connection is Established_ and that the
WebSocket Connection is in the OPEN state. The _Extensions In Use_ WebSocket Connection is in the OPEN state. The _Extensions In Use_
is defined to be a (possibly empty) string, the value of which is is defined to be a (possibly empty) string, the value of which is
equal to the value of the |Sec-WebSocket-Extensions| header supplied equal to the value of the |Sec-WebSocket-Extensions| header field
by the server's handshake, or the null value if that header was not supplied by the server's handshake, or the null value if that header
present in the server's handshake. The _Subprotocol In Use_ is field was not present in the server's handshake. The _Subprotocol In
defined to be the value of the |Sec-WebSocket-Protocol| header in the Use_ is defined to be the value of the |Sec-WebSocket-Protocol|
server's handshake, or the null value if that header was not present header field in the server's handshake, or the null value if that
in the server's handshake. Additionally, if any headers in the header field was not present in the server's handshake.
server's handshake indicate that cookies should be set (as defined by Additionally, if any header fields in the server's handshake indicate
[RFC6265]), these cookies are referred to as _Cookies Set During the that cookies should be set (as defined by [RFC6265]), these cookies
Server's Opening Handshake_. are referred to as _Cookies Set During the Server's Opening
Handshake_.
5.2. Server-side Requirements 5.2. Server-side Requirements
_This section only applies to servers._ _This section only applies to servers._
Servers MAY offload the management of the connection to other agents Servers MAY offload the management of the connection to other agents
on the network, for example load balancers and reverse proxies. In on the network, for example load balancers and reverse proxies. In
such a situation, the server for the purposes of conformance is such a situation, the server for the purposes of conformance is
considered to include all parts of the server-side infrastructure considered to include all parts of the server-side infrastructure
from the first device to terminate the TCP connection all the way to from the first device to terminate the TCP connection all the way to
skipping to change at page 33, line 22 skipping to change at page 33, line 17
The client's opening handshake consists of the following parts. If The client's opening handshake consists of the following parts. If
the server, while reading the handshake, finds that the client did the server, while reading the handshake, finds that the client did
not send a handshake that matches the description below, including not send a handshake that matches the description below, including
but not limited to any violations of the grammar (ABNF) specified for but not limited to any violations of the grammar (ABNF) specified for
the components of the handshake, the server MUST stop processing the the components of the handshake, the server MUST stop processing the
client's handshake, and return an HTTP response with an appropriate client's handshake, and return an HTTP response with an appropriate
error code (such as 400 Bad Request). error code (such as 400 Bad Request).
1. An HTTP/1.1 or higher GET request, including a "Request-URI" 1. An HTTP/1.1 or higher GET request, including a "Request-URI"
[RFC2616] that should be interpreted as a /resource name/ [RFC2616] that should be interpreted as a /resource name/
Section 3. Section 3 (or an absolute HTTP/HTTPS URI containing the /resource
name/).
2. A "Host" header containing the server's authority. 2. A "Host" header field containing the server's authority.
3. A "Sec-WebSocket-Key" header with a base64-encoded (see Section 4 3. A "Sec-WebSocket-Key" header field with a base64-encoded (see
of [RFC4648]) value that, when decoded, is 16 bytes in length. Section 4 of [RFC4648]) value that, when decoded, is 16 bytes in
length.
4. A "Sec-WebSocket-Version" header, with a value of 8. 4. A "Sec-WebSocket-Version" header field, with a value of 8.
5. Optionally, a "Sec-WebSocket-Origin" header. This header is sent 5. Optionally, a "Origin" header field. This header field is sent
by all browser clients. A connection attempt lacking this header by all browser clients. A connection attempt lacking this header
SHOULD NOT be interpreted as coming from a browser client. field SHOULD NOT be interpreted as coming from a browser client.
6. Optionally, a "Sec-WebSocket-Protocol" header, with a list of 6. Optionally, a "Sec-WebSocket-Protocol" header field, with a list
values indicating which protocols the client would like to speak, of values indicating which protocols the client would like to
ordered by preference. speak, ordered by preference.
7. Optionally, a "Sec-WebSocket-Extensions" header, with a list of 7. Optionally, a "Sec-WebSocket-Extensions" header field, with a
values indicating which extensions the client would like to list of values indicating which extensions the client would like
speak. The interpretation of this header is discussed in to speak. The interpretation of this header field is discussed
Section 9.1. in Section 9.1.
8. Optionally, other headers, such as those used to send cookies to 8. Optionally, other header fields, such as those used to send
a server. Unknown headers MUST be ignored. cookies to a server. Unknown header fields MUST be ignored.
5.2.2. Sending the Server's Opening Handshake 5.2.2. Sending the Server's Opening Handshake
When a client establishes a WebSocket connection to a server, the When a client establishes a WebSocket connection to a server, the
server MUST complete the following steps to accept the connection and server MUST complete the following steps to accept the connection and
send the server's opening handshake. send the server's opening handshake.
1. If the server supports encryption, perform a TLS handshake over 1. If the server supports encryption, perform a TLS handshake over
the connection. If this fails (e.g. the client indicated a host the connection. If this fails (e.g. the client indicated a host
name in the extended client hello "server_name" extension that name in the extended client hello "server_name" extension that
the server does not host), then close the connection; otherwise, the server does not host), then close the connection; otherwise,
all further communication for the connection (including the all further communication for the connection (including the
server's handshake) MUST run through the encrypted tunnel. server's handshake) MUST run through the encrypted tunnel.
[RFC5246] [RFC5246]
2. Establish the following information: 2. Establish the following information:
/origin/ /origin/
The |Sec-WebSocket-Origin| header in the client's handshake The |Origin| header field in the client's handshake indicates
indicates the origin of the script establishing the the origin of the script establishing the connection. The
connection. The origin is serialized to ASCII and converted origin is serialized to ASCII and converted to lowercase. The
to lowercase. The server MAY use this information as part of server MAY use this information as part of a determination of
a determination of whether to accept the incoming connection. whether to accept the incoming connection. If the server does
If the server does not validate the origin, it will accept not validate the origin, it will accept connections from
connections from anywhere. If the server does not wish to anywhere. If the server does not wish to accept this
accept this connection, it MUST return an appropriate HTTP connection, it MUST return an appropriate HTTP error code
error code (e.g. 403 Forbidden) and abort the WebSocket (e.g. 403 Forbidden) and abort the WebSocket handshake
handshake described in this section. For more detail, refer described in this section. For more detail, refer to
to Section 10. Section 10.
/key/ /key/
The |Sec-WebSocket-Key| header in the client's handshake The |Sec-WebSocket-Key| header field in the client's handshake
includes a base64-encoded value that, if decoded, is 16 bytes includes a base64-encoded value that, if decoded, is 16 bytes
in length. This (encoded) value is used in the creation of in length. This (encoded) value is used in the creation of
the server's handshake to indicate an acceptance of the the server's handshake to indicate an acceptance of the
connection. It is not necessary for the server to base64- connection. It is not necessary for the server to base64-
decode the "Sec-WebSocket-Key" value. decode the "Sec-WebSocket-Key" value.
/version/ /version/
The |Sec-WebSocket-Version| header in the client's handshake The |Sec-WebSocket-Version| header field in the client's
includes the version of the WebSocket protocol the client is handshake includes the version of the WebSocket protocol the
attempting to communicate with. If this version does not client is attempting to communicate with. If this version
match a version understood by the server, the server MUST does not match a version understood by the server, the server
abort the websocket handshake described in this section and MUST abort the websocket handshake described in this section
instead send an appropriate HTTP error code (such as 426 and instead send an appropriate HTTP error code (such as 426
Upgrade Required), and a |Sec-WebSocket-Version| header Upgrade Required), and a |Sec-WebSocket-Version| header field
indicating the version(s) the server is capable of indicating the version(s) the server is capable of
understanding. understanding.
/resource name/ /resource name/
An identifier for the service provided by the server. If the An identifier for the service provided by the server. If the
server provides multiple services, then the value should be server provides multiple services, then the value should be
derived from the resource name given in the client's handshake derived from the resource name given in the client's handshake
from the Request-URI [RFC2616] of the GET method. If the from the Request-URI [RFC2616] of the GET method. If the
requested service is not available, the server MUST send an requested service is not available, the server MUST send an
appropriate HTTP error code (such as 404 Not Found) and abort appropriate HTTP error code (such as 404 Not Found) and abort
the WebSocket handshake. the WebSocket handshake.
/subprotocol/ /subprotocol/
Either a single value representing the subprotocol the server Either a single value representing the subprotocol the server
is ready to use or null. The value chosen MUST be derived is ready to use or null. The value chosen MUST be derived
from the client's handshake, specifically by selecting one of from the client's handshake, specifically by selecting one of
the values from the "Sec-WebSocket-Protocol" field that the the values from the "Sec-WebSocket-Protocol" field that the
server is willing to use for this connection (if any). If the server is willing to use for this connection (if any). If the
client's handshake did not contain such a header, or if the client's handshake did not contain such a header field, or if
server does not agree to any of the client's requested the server does not agree to any of the client's requested
subprotocols, the only acceptable value is null. The absence subprotocols, the only acceptable value is null. The absence
of such a field is equivalent to the null value (meaning that of such a field is equivalent to the null value (meaning that
if the server does not wish to agree to one of the suggested if the server does not wish to agree to one of the suggested
subprotocols, it MUST NOT send back a |Sec-WebSocket-Protocol| subprotocols, it MUST NOT send back a |Sec-WebSocket-Protocol|
header in its response). The empty string is not the same as header field in its response). The empty string is not the
the null value for these purposes, and is not a legal value same as the null value for these purposes, and is not a legal
for this field. The ABNF for the value of this header is value for this field. The ABNF for the value of this header
(token), where the definitions of constructs and rules are as field is (token), where the definitions of constructs and
given in [RFC2616]. rules are as given in [RFC2616].
/extensions/ /extensions/
A (possibly empty) list representing the protocol-level A (possibly empty) list representing the protocol-level
extensions the server is ready to use. If the server supports extensions the server is ready to use. If the server supports
multiple extensions, then the value MUST be derived from the multiple extensions, then the value MUST be derived from the
client's handshake, specifically by selecting one or more of client's handshake, specifically by selecting one or more of
the values from the "Sec-WebSocket-Extensions" field. The the values from the "Sec-WebSocket-Extensions" field. The
absence of such a field is equivalent to the null value. The absence of such a field is equivalent to the null value. The
empty string is not the same as the null value for these empty string is not the same as the null value for these
purposes. Extensions not listed by the client MUST NOT be purposes. Extensions not listed by the client MUST NOT be
listed. The method by which these values should be selected listed. The method by which these values should be selected
and interpreted is discussed in Section 9.1. and interpreted is discussed in Section 9.1.
3. If the server chooses to accept the incoming connection, it MUST 3. If the server chooses to accept the incoming connection, it MUST
reply with a valid HTTP response indicating the following. reply with a valid HTTP response indicating the following.
1. A Status-Line with a 101 response code as per RFC 2616 1. A Status-Line with a 101 response code as per RFC 2616
[RFC2616]. Such a response could look like "HTTP/1.1 101 [RFC2616]. Such a response could look like "HTTP/1.1 101
Switching Protocols" Switching Protocols"
2. An "Upgrade" header with value "websocket" as per RFC 2616 2. An "Upgrade" header field with value "websocket" as per RFC
[RFC2616]. 2616 [RFC2616].
3. A "Connection" header with value "Upgrade" 3. A "Connection" header field with value "Upgrade"
4. A "Sec-WebSocket-Accept" header. The value of this header is 4. A "Sec-WebSocket-Accept" header field. The value of this
constructed by concatenating /key/, defined above in header field is constructed by concatenating /key/, defined
Paragraph 2 of Section 5.2.2, with the string "258EAFA5-E914- above in Paragraph 2 of Section 5.2.2, with the string
47DA-95CA-C5AB0DC85B11", taking the SHA-1 hash of this "258EAFA5-E914-47DA-95CA-C5AB0DC85B11", taking the SHA-1 hash
concatenated value to obtain a 20-byte value, and base64- of this concatenated value to obtain a 20-byte value, and
encoding (see Section 4 of [RFC4648]) this 20-byte hash. base64-encoding (see Section 4 of [RFC4648]) this 20-byte
hash.
The ABNF of this header is defined as follows: The ABNF of this header field is defined as follows:
accept-value = base64-value Sec-WebSocket-Accept = base64-value
base64-value = *base64-data [ base64-padding ] base64-value = *base64-data [ base64-padding ]
base64-data = 4base64-character base64-data = 4base64-character
base64-padding = (2base64-character "==") / (3base64-character "=") base64-padding = (2base64-character "==") | (3base64-character "=")
base64-character = ALPHA / DIGIT / "+" / "/" base64-character = ALPHA | DIGIT | "+" | "/"
NOTE: As an example, if the value of the "Sec-WebSocket-Key" NOTE: As an example, if the value of the "Sec-WebSocket-Key"
header in the client's handshake were header field in the client's handshake were
"dGhlIHNhbXBsZSBub25jZQ==", the server would append the "dGhlIHNhbXBsZSBub25jZQ==", the server would append the
string "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" to form the string "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" to form the
string "dGhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CA- string "dGhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CA-
C5AB0DC85B11". The server would then take the SHA-1 hash of C5AB0DC85B11". The server would then take the SHA-1 hash of
this string, giving the value 0xb3 0x7a 0x4f 0x2c 0xc0 0x62 this string, giving the value 0xb3 0x7a 0x4f 0x2c 0xc0 0x62
0x4f 0x16 0x90 0xf6 0x46 0x06 0xcf 0x38 0x59 0x45 0xb2 0xbe 0x4f 0x16 0x90 0xf6 0x46 0x06 0xcf 0x38 0x59 0x45 0xb2 0xbe
0xc4 0xea. This value is then base64-encoded, to give the 0xc4 0xea. This value is then base64-encoded, to give the
value "s3pPLMBiTxaQ9kYGzzhZRbK+xOo=", which would be returned value "s3pPLMBiTxaQ9kYGzzhZRbK+xOo=", which would be returned
in the "Sec-WebSocket-Accept" header. in the "Sec-WebSocket-Accept" header field.
5. Optionally, a "Sec-WebSocket-Protocol" header, with a value 5. Optionally, a "Sec-WebSocket-Protocol" header field, with a
/subprotocol/ as defined in Paragraph 2 of Section 5.2.2. value /subprotocol/ as defined in Paragraph 2 of
Section 5.2.2.
6. Optionally, a "Sec-WebSocket-Extensions" header, with a value 6. Optionally, a "Sec-WebSocket-Extensions" header field, with a
/extensions/ as defined in Paragraph 2 of Section 5.2.2. If value /extensions/ as defined in Paragraph 2 of
multiple extensions are to be used, they must all be listed Section 5.2.2. If multiple extensions are to be used, they
in a single Sec-WebSocket-Extensions header. This header must all be listed in a single Sec-WebSocket-Extensions
MUST NOT be repeated. header field. This header field MUST NOT be repeated.
This completes the server's handshake. If the server finishes these This completes the server's handshake. If the server finishes these
steps without aborting the WebSocket handshake, the server considers steps without aborting the WebSocket handshake, the server considers
the WebSocket connection to be established and that the WebSocket the WebSocket connection to be established and that the WebSocket
connection is in the OPEN state. At this point, the server may begin connection is in the OPEN state. At this point, the server may begin
sending (and receiving) data. sending (and receiving) data.
5.3. Collected ABNF for new header fields used in handshake
Unlike other section of the document this section is using ABNF
syntax/rules from [RFC2616], including "implied WSP rule".
The following new header field can be sent during the handshake from
the client to the server:
Sec-WebSocket-Key = base64-value
Sec-WebSocket-Extensions = extension-list
Sec-WebSocket-Protocol-Client = 1#token
Sec-WebSocket-Version-Client = version
base64-value = *base64-data [ base64-padding ]
base64-data = 4base64-character
base64-padding = (2base64-character "==") | (3base64-character "=")
base64-character = ALPHA | DIGIT | "+" | "/"
extension-list = 1#extension
extension = extension-token *( ";" extension-param )
extension-token = registered-token | private-use-token
registered-token = token
private-use-token = "x-" token
extension-param = token [ "=" token ]
version = "0" | ("1" DIGIT DIGIT) | ("2" DIGIT DIGIT)
; 0-255
The following new header field can be sent during the handshake from
the server to the client:
Sec-WebSocket-Extensions = extension-list
Sec-WebSocket-Accept = base64-value
Sec-WebSocket-Protocol-Server = token
Sec-WebSocket-Version-Server = 1#version
6. Sending and Receiving Data 6. Sending and Receiving Data
6.1. Sending Data 6.1. Sending Data
To _Send a WebSocket Message_ comprising of /data/ over a WebSocket To _Send a WebSocket Message_ comprising of /data/ over a WebSocket
connection, an endpoint MUST perform the following steps. connection, an endpoint MUST perform the following steps.
1. The endpoint MUST ensure the WebSocket connection is in the OPEN 1. The endpoint MUST ensure the WebSocket connection is in the OPEN
state (cf. Section 5.1 and Section 5.2.2.) If at any point the state (cf. Section 5.1 and Section 5.2.2.) If at any point the
state of the WebSocket connection changes, the endpoint MUST state of the WebSocket connection changes, the endpoint MUST
skipping to change at page 41, line 18 skipping to change at page 42, line 18
NOTE: Following the same logic as noted in Section 7.1.5, two NOTE: Following the same logic as noted in Section 7.1.5, two
endpoints may not agree on _The WebSocket Connection Close Reason_. endpoints may not agree on _The WebSocket Connection Close Reason_.
7.1.7. Fail the WebSocket Connection 7.1.7. Fail the WebSocket Connection
Certain algorithms and specifications require an endpoint to _Fail Certain algorithms and specifications require an endpoint to _Fail
the WebSocket Connection_. To do so, the client MUST _Close the the WebSocket Connection_. To do so, the client MUST _Close the
WebSocket Connection_, and MAY report the problem to the user (which WebSocket Connection_, and MAY report the problem to the user (which
would be especially useful for developers) in an appropriate manner. would be especially useful for developers) in an appropriate manner.
Similarly, to do so, the server MUST _Close the WebSocket
Connection_, and SHOULD log the problem.
If _The WebSocket Connection is Established_ prior to the point where If _The WebSocket Connection is Established_ prior to the point where
the endpoint is required to _Fail the WebSocket Connection_, the the endpoint is required to _Fail the WebSocket Connection_, the
endpoint SHOULD send a Close frame with an appropriate status code endpoint SHOULD send a Close frame with an appropriate status code
Section 7.4 before proceeding to _Close the WebSocket Connection_. Section 7.4 before proceeding to _Close the WebSocket Connection_.
An endpoint MAY omit sending a Close frame if it believes the other An endpoint MAY omit sending a Close frame if it believes the other
side is unlikely to be able to receive and process the close frame, side is unlikely to be able to receive and process the close frame,
due to the nature of the error that led to the WebSocket connection due to the nature of the error that led to the WebSocket connection
being failed in the first place. An endpoint MUST NOT continue to being failed in the first place. An endpoint MUST NOT continue to
attempt to process data (including a responding Close frame) from the attempt to process data (including a responding Close frame) from the
skipping to change at page 43, line 44 skipping to change at page 44, line 44
1007 indicates that an endpoint is terminating the connection 1007 indicates that an endpoint is terminating the connection
because it has received data that was supposed to be UTF-8 (such because it has received data that was supposed to be UTF-8 (such
as in a text frame) that was in fact not valid UTF-8 [RFC3629]. as in a text frame) that was in fact not valid UTF-8 [RFC3629].
7.4.2. Reserved Status Code Ranges 7.4.2. Reserved Status Code Ranges
0-999 0-999
Status codes in the range 0-999 are not used. Status codes in the range 0-999 are not used.
1000-1999 1000-2999
Status codes in the range 1000-1999 are reserved for definition by
this protocol.
2000-2999
Status codes in the range 2000-2999 are reserved for use by Status codes in the range 1000-2999 are reserved for definition by
extensions. this protocol, its future revisions, and extensions specified in a
permanent and readily available public specification.
3000-3999 3000-3999
Status codes in the range 3000-3999 MAY be used by libraries and Status codes in the range 3000-3999 are reserved for use by
frameworks. The interpretation of these codes is undefined by libraries, frameworks and application. These status codes are
this protocol. End applications MUST NOT use status codes in this registered directly with IANA. The interpretation of these codes
range. is undefined by this protocol.
4000-4999 4000-4999
Status codes in the range 4000-4999 MAY be used by application Status codes in the range 4000-4999 are reserved for private use
code. The interpretation of these codes is undefined by this and thus can't be registered. Such codes can be used by prior
protocol. agreements between WebSocket applications. The interpretation of
these codes is undefined by this protocol.
8. Error Handling 8. Error Handling
8.1. Handling Errors in UTF-8 Encoded Data 8.1. Handling Errors in UTF-8 Encoded Data
When an endpoint is to interpret a byte stream as UTF-8 but finds When an endpoint is to interpret a byte stream as UTF-8 but finds
that the byte stream is not in fact a valid UTF-8 stream, that that the byte stream is not in fact a valid UTF-8 stream, that
endpoint MUST _Fail the WebSocket Connection_. endpoint MUST _Fail the WebSocket Connection_.
9. Extensions 9. Extensions
skipping to change at page 46, line 18 skipping to change at page 47, line 18
WebSocket servers MAY accept some or all extensions requested by the WebSocket servers MAY accept some or all extensions requested by the
client. A server MUST NOT respond with any extension not requested client. A server MUST NOT respond with any extension not requested
by the client. If extension parameters are included in negotiations by the client. If extension parameters are included in negotiations
between the client and the server, those parameters MUST be chosen in between the client and the server, those parameters MUST be chosen in
accordance with the specification of the extension to which the accordance with the specification of the extension to which the
parameters apply. parameters apply.
9.1. Negotiating Extensions 9.1. Negotiating Extensions
A client requests extensions by including a "Sec-WebSocket- A client requests extensions by including a "Sec-WebSocket-
Extensions" header, which follows the normal rules for HTTP headers Extensions" header field, which follows the normal rules for HTTP
(see [RFC2616] section 4.2) and the value of the header is defined by header fields (see [RFC2616] section 4.2) and the value of the header
the following ABNF. Note that unlike other section of the document field is defined by the following ABNF. Note that unlike other
this section is using ABNF syntax/rules from [RFC2616]. If a value section of the document this section is using ABNF syntax/rules from
is received by either the client or the server during negotiation [RFC2616], including "implied WSP rule". If a value is received by
that does not conform to the ABNF below, the recipient of such either the client or the server during negotiation that does not
malformed data MUST immediately _Fail the WebSocket Connection_. conform to the ABNF below, the recipient of such malformed data MUST
immediately _Fail the WebSocket Connection_.
Sec-WebSocket-Extensions = extension-list
extension-list = 1#extension extension-list = 1#extension
extension = extension-token *( ";" extension-param ) extension = extension-token *( ";" extension-param )
extension-token = registered-token / private-use-token extension-token = registered-token | private-use-token
registered-token = token registered-token = token
private-use-token = "x-" token private-use-token = "x-" token
extension-param = token [ "=" token ] extension-param = token [ "=" token ]
Note that like other HTTP headers, this header MAY be split or Note that like other HTTP header fields, this header field MAY be
combined across multiple lines. Ergo, the following are equivalent: split or combined across multiple lines. Ergo, the following are
equivalent:
Sec-WebSocket-Extensions: foo Sec-WebSocket-Extensions: foo
Sec-WebSocket-Extensions: bar; baz=2 Sec-WebSocket-Extensions: bar; baz=2
is exactly equivalent to is exactly equivalent to
Sec-WebSocket-Extensions: foo, bar; baz=2 Sec-WebSocket-Extensions: foo, bar; baz=2
Any extension-token used MUST either be a registered token (see Any extension-token used MUST either be a registered token (see
Section 11.6), or have a prefix of "x-" to indicate a private-use Section 11.4), or have a prefix of "x-" to indicate a private-use
token. The parameters supplied with any given extension MUST be token. The parameters supplied with any given extension MUST be
defined for that extension. Note that the client is only offering to defined for that extension. Note that the client is only offering to
use any advertised extensions, and MUST NOT use them unless the use any advertised extensions, and MUST NOT use them unless the
server indicates that it wishes to use the extension. server indicates that it wishes to use the extension.
Note that the order of extensions is significant. Any interactions Note that the order of extensions is significant. Any interactions
between multiple extensions MAY be defined in the documents defining between multiple extensions MAY be defined in the documents defining
the extensions. In the absence of such definition, the the extensions. In the absence of such definition, the
interpretation is that the headers listed by the client in its interpretation is that the header fields listed by the client in its
request represent a preference of the headers it wishes to use, with request represent a preference of the header fields it wishes to use,
the first options listed being most preferable. The extensions with the first options listed being most preferable. The extensions
listed by the server in response represent the extensions actually in listed by the server in response represent the extensions actually in
use for the connection. Should the extensions modify the data and/or 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 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 the same as the order in which the extensions are listed in the
server's response in the opening handshake. server's response in the opening handshake.
For example, if there are two extensions "foo" and "bar", if the For example, if there are two extensions "foo" and "bar", if the
header |Sec-WebSocket-Extensions| sent by the server has the value header field |Sec-WebSocket-Extensions| sent by the server has the
"foo, bar" then operations on the data will be made as value "foo, bar" then operations on the data will be made as
bar(foo(data)), be those changes to the data itself (such as bar(foo(data)), be those changes to the data itself (such as
compression) or changes to the framing thay may "stack". compression) or changes to the framing thay may "stack".
Non-normative examples of acceptable extension headers: Non-normative examples of acceptable extension header fields:
Sec-WebSocket-Extensions: deflate-stream Sec-WebSocket-Extensions: deflate-stream
Sec-WebSocket-Extensions: mux; max-channels=4; flow-control, deflate-stream Sec-WebSocket-Extensions: mux; max-channels=4; flow-control, deflate-stream
Sec-WebSocket-Extensions: x-private-extension Sec-WebSocket-Extensions: x-private-extension
A server accepts one or more extensions by including a |Sec- A server accepts one or more extensions by including a |Sec-
WebSocket-Extensions| header containing one or more extensions which WebSocket-Extensions| header field containing one or more extensions
were requested by the client. The interpretation of any extension which were requested by the client. The interpretation of any
parameters, and what constitutes a valid response by a server to a extension parameters, and what constitutes a valid response by a
requested set of parameters by a client, will be defined by each such server to a requested set of parameters by a client, will be defined
extension. by each such extension.
9.2. Known Extensions 9.2. Known Extensions
Extensions provide a mechanism for implementations to opt-in to Extensions provide a mechanism for implementations to opt-in to
additional protocol features. This section defines the meaning of additional protocol features. This document doesn't define any
well-known extensions but implementations MAY use extensions defined extension but implementations MAY use extensions defined separately.
separately as well.
9.2.1. Compression
The registered extension token for this compression extension is
"deflate-stream".
The extension does not have any per frame extension data and it does
not define the use of any WebSocket reserved bits or opcodes.
Senders using this extension MUST apply [RFC1951] encodings to all
bytes of the data stream following the opening handshake including
both data and control frames. The data stream MAY include multiple
blocks of both compressed and uncompressed types as defined by
[RFC1951].
Senders MUST NOT delay the transmission of any portion of a WebSocket
frame because the deflate encoding of the frame does not end on a
byte boundary. The encodings for adjacent frames MAY appear in the
same byte if no delay in transmission is occurred by doing so.
Historically there have been some confusion and interoperability
problems around the specification of compression algorithms. In this
specification "deflate-stream" requires a [RFC1951] deflate encoding.
It MUST NOT be wrapped in any of the header formats often associated
with RFC 1951 such as "zlib" [RFC1950]. This requirement is given
special attention with this note because of confusion in this area,
the presence of some popular open source libraries that create both
formats under a single API call with confusing naming conventions,
and the fact that the popular HTTP [RFC2616] specification defines
"deflate" compression differently than this specification.
10. Security Considerations 10. Security Considerations
While this protocol is intended to be used by scripts in Web pages, While this protocol is intended to be used by scripts in Web pages,
it can also be used directly by hosts. Such hosts are acting on it can also be used directly by hosts. Such hosts are acting on
their own behalf, and can therefore send fake "Origin" fields, their own behalf, and can therefore send fake "Origin" header fields,
misleading the server. Servers should therefore be careful about misleading the server. Servers should therefore be careful about
assuming that they are talking directly to scripts from known assuming that they are talking directly to scripts from known
origins, and must consider that they might be accessed in unexpected origins, and must consider that they might be accessed in unexpected
ways. In particular, a server should not trust that any input is ways. In particular, a server should not trust that any input is
valid. valid.
EXAMPLE: For example, if the server uses input as part of SQL EXAMPLE: For example, if the server uses input as part of SQL
queries, all input text should be escaped before being passed to the queries, all input text should be escaped before being passed to the
SQL server, lest the server be susceptible to SQL injection. SQL server, lest the server be susceptible to SQL injection.
Servers that are not intended to process input from any Web page but Servers that are not intended to process input from any Web page but
only for certain sites SHOULD verify the "Origin" field is an origin only for certain sites SHOULD verify the "Origin" field is an origin
they expect, and should only respond with the corresponding "Sec- they expect, and should only respond with the corresponding "Sec-
WebSocket-Origin" if it is an accepted origin. Servers that only WebSocket-Accept" if it is an accepted origin.
accept input from one origin can just send back that value in the
"Sec-WebSocket-Origin" field, without bothering to check the client's The "Origin" header field protects from the attack cases when the
value. untrusted party is typically the author of a JavaScript application
that is executing in the context of the trusted client. The client
itself can contact the server and via the mechanism of the "Origin"
header field, determine whether to extend those communication
privileges to the JavaScript application. The intent is not to
prevent non-browsers from establishing connections, but rather to
ensure that trusted browsers under the control of potentially
malicious JavaScript cannot fake a WebSocket handshake.
This document doesn't prescribe any particular way that servers can
authenticate clients during the WebSocket handshake. The WebSocket
server can use any client authentication mechanism available to a
generic HTTP server, such as Cookies, HTTP Authentication, TLS
authentication.
If at any time a server is faced with data that it does not If at any time a server is faced with data that it does not
understand, or that violates some criteria by which the server understand, or that violates some criteria by which the server
determines safety of input, or when the server sees an opening determines safety of input, or when the server sees an opening
handshake that does not correspond to the values the server is handshake that does not correspond to the values the server is
expecting (e.g. incorrect path or origin), the server SHOULD just expecting (e.g. incorrect path or origin), the server MAY drop the
disconnect. It is always safe to disconnect. TCP connection. If the invalid data received after a successful
WebSocket handshake, the server SHOULD send a Close frame with an
appropriate status code Section 7.4 before proceeding to _Close the
WebSocket Connection_. Use of a Close frame with an appropriate
status code can help in diagnosing the problem. If the invalid data
is sent during the WebSocket handshake the server SHOULD return an
appropriate HTTP [RFC2616] status code.
A common class of security problems arise when sending text data A common class of security problems arise when sending text data
using using the wrong encoding. This protocol specifies that using using the wrong encoding. This protocol specifies that
messages with a Text data type (as opposed to Binary or other types) messages with a Text data type (as opposed to Binary or other types)
contain UTF-8 encoded data. Although the length is still indicated contain UTF-8 encoded data. Although the length is still indicated
and applications implementing this protocol should use the length to and applications implementing this protocol should use the length to
determine where the frame actually ends, sending data in an improper determine where the frame actually ends, sending data in an improper
encoding may still break assumptions applications built on top of encoding may still break assumptions applications built on top of
this protocol may make, leading from anything to misinterpretation of this protocol may make, leading from anything to misinterpretation of
data to loss of data to potential security bugs. data to loss of data to potential security bugs.
skipping to change at page 50, line 18 skipping to change at page 50, line 37
back a frame that is interpreted as a cacheable response to that back a frame that is interpreted as a cacheable response to that
request, thus poisioning the cache for other users. To prevent this request, thus poisioning the cache for other users. To prevent this
attack, frames sent from clients are masked on the wire with a 32-bit attack, frames sent from clients are masked on the wire with a 32-bit
value, to prevent an attacker from controlling the bits on the wire value, to prevent an attacker from controlling the bits on the wire
and thus lessen the probability of an attacker being able to and thus lessen the probability of an attacker being able to
construct a frame that can be misinterpreted by a proxy as a non- construct a frame that can be misinterpreted by a proxy as a non-
WebSocket request. WebSocket request.
For connections using TLS (wss: URIs), the amount of benefit provided For connections using TLS (wss: URIs), the amount of benefit provided
by TLS depends greatly on the strength of the algorithms negotiated by TLS depends greatly on the strength of the algorithms negotiated
during the TLS handshake. To achieve reasonable levels of during the TLS handshake. For example some TLS cipher mechanisms
protections, clients should use only Strong TLS algorithms. "Web don't provide connection confidentiality. To achieve reasonable
Security Context: User Interface Guidelines" levels of protections, clients should use only Strong TLS algorithms.
"Web Security Context: User Interface Guidelines"
[W3C.REC-wsc-ui-20100812] discusses what constitutes Strong TLS [W3C.REC-wsc-ui-20100812] discusses what constitutes Strong TLS
algorithms. algorithms.
Implementations MAY impose implementation-specific limits on
otherwise unconstrained inputs, e.g. to prevent denial of service
attacks, to guard against running out of memory, or to work around
platform-specific limitations. For example implementations might
impose limit on frame sizes and the total message size after
reassembly from multiple frames.
11. IANA Considerations 11. IANA Considerations
11.1. Registration of "ws:" Scheme 11.1. Registration of new URI Schemes
11.1.1. Registration of "ws:" Scheme
A |ws:| URI identifies a WebSocket server and resource name. A |ws:| URI identifies a WebSocket server and resource name.
URI scheme name. URI scheme name.
ws ws
Status. Status.
Permanent. Permanent.
URI scheme syntax. URI scheme syntax.
In ABNF terms using the terminals from the URI specifications: In ABNF terms using the terminals from the URI specifications:
[RFC5234] [RFC3986] [RFC5234] [RFC3986]
"ws" ":" hier-part [ "?" query ] "ws:" "//" authority path-abempty [ "?" query ]
The <path> [RFC3986] and <query> components form the resource name The <path-abempty> and <query> [RFC3986] components form the
sent to the server to identify the kind of service desired. Other resource name sent to the server to identify the kind of service
components have the meanings described in RFC3986. desired. Other components have the meanings described in RFC3986.
URI scheme semantics. URI scheme semantics.
The only operation for this scheme is to open a connection using The only operation for this scheme is to open a connection using
the WebSocket protocol. the WebSocket protocol.
Encoding considerations. Encoding considerations.
Characters in the host component that are excluded by the syntax Characters in the host component that are excluded by the syntax
defined above MUST be converted from Unicode to ASCII by applying defined above MUST be converted from Unicode to ASCII by applying
the IDNA ToASCII algorithm to the Unicode host name, with both the the IDNA ToASCII algorithm to the Unicode host name, with both the
AllowUnassigned and UseSTD3ASCIIRules flags set, and using the AllowUnassigned and UseSTD3ASCIIRules flags set, and using the
skipping to change at page 52, line 17 skipping to change at page 53, line 17
Contact. Contact.
HYBI WG <hybi@ietf.org> HYBI WG <hybi@ietf.org>
Author/Change controller. Author/Change controller.
IETF <iesg@ietf.org> IETF <iesg@ietf.org>
References. References.
RFC XXXX RFC XXXX
11.2. Registration of "wss:" Scheme 11.1.2. Registration of "wss:" Scheme
A |wss:| URI identifies a WebSocket server and resource name, and A |wss:| URI identifies a WebSocket server and resource name, and
indicates that traffic over that connection is to be protected via indicates that traffic over that connection is to be protected via
TLS (including standard benefits of TLS such as confidentiality, TLS (including standard benefits of TLS such as data confidentiality
integrity, and authentication). and integrity, and endpoint authentication).
URI scheme name. URI scheme name.
wss wss
Status. Status.
Permanent. Permanent.
URI scheme syntax. URI scheme syntax.
In ABNF terms using the terminals from the URI specifications: In ABNF terms using the terminals from the URI specifications:
[RFC5234] [RFC3986] [RFC5234] [RFC3986]
"wss" ":" hier-part [ "?" query ] "wss:" "//" authority path-abempty [ "?" query ]
The <path> and <query> components form the resource name sent to The <path-abempty> and <query> components form the resource name
the server to identify the kind of service desired. Other sent to the server to identify the kind of service desired. Other
components have the meanings described in RFC3986. components have the meanings described in RFC3986.
URI scheme semantics. URI scheme semantics.
The only operation for this scheme is to open a connection using The only operation for this scheme is to open a connection using
the WebSocket protocol, encrypted using TLS. the WebSocket protocol, encrypted using TLS.
Encoding considerations. Encoding considerations.
Characters in the host component that are excluded by the syntax Characters in the host component that are excluded by the syntax
defined above MUST be converted from Unicode to ASCII by applying defined above MUST be converted from Unicode to ASCII by applying
the IDNA ToASCII algorithm to the Unicode host name, with both the the IDNA ToASCII algorithm to the Unicode host name, with both the
skipping to change at page 53, line 26 skipping to change at page 54, line 26
Contact. Contact.
HYBI WG <hybi@ietf.org> HYBI WG <hybi@ietf.org>
Author/Change controller. Author/Change controller.
IETF <iesg@ietf.org> IETF <iesg@ietf.org>
References. References.
RFC XXXX RFC XXXX
11.3. Registration of the "WebSocket" HTTP Upgrade Keyword 11.2. Registration of the "WebSocket" HTTP Upgrade Keyword
This section defines a keyword for registration in the "HTTP Upgrade This section defines a keyword for registration in the "HTTP Upgrade
Tokens" registry as per RFC 2817 [RFC2817]. Tokens" registry as per RFC 2817 [RFC2817].
Name of token. Name of token.
WebSocket WebSocket
Author/Change controller. Author/Change controller.
IETF <iesg@ietf.org> IETF <iesg@ietf.org>
Contact. Contact.
HYBI <hybi@ietf.org> HYBI <hybi@ietf.org>
References. References.
RFC XXXX RFC XXXX
11.4. Sec-WebSocket-Key 11.3. Registration of new HTTP Header Fields
11.3.1. Sec-WebSocket-Key
This section describes a header field for registration in the This section describes a header field for registration in the
Permanent Message Header Field Registry. [RFC3864] Permanent Message Header Field Registry. [RFC3864]
Header field name Header field name
Sec-WebSocket-Key Sec-WebSocket-Key
Applicable protocol Applicable protocol
http http
Status Status
skipping to change at page 54, line 22 skipping to change at page 55, line 22
Author/Change controller Author/Change controller
IETF IETF
Specification document(s) Specification document(s)
RFC XXXX RFC XXXX
Related information Related information
This header field is only used for WebSocket opening handshake. This header field is only used for WebSocket opening handshake.
The |Sec-WebSocket-Key| header is used in the WebSocket opening The |Sec-WebSocket-Key| header field is used in the WebSocket opening
handshake. It is sent from the client to the server to provide part handshake. It is sent from the client to the server to provide part
of the information used by the server to prove that it received a of the information used by the server to prove that it received a
valid WebSocket opening handshake. This helps ensure that the server valid WebSocket opening handshake. This helps ensure that the server
does not accept connections from non-WebSocket clients (e.g. HTTP does not accept connections from non-WebSocket clients (e.g. HTTP
clients) that are being abused to send data to unsuspecting WebSocket clients) that are being abused to send data to unsuspecting WebSocket
servers. servers.
11.5. Sec-WebSocket-Extensions 11.3.2. Sec-WebSocket-Extensions
This section describes a header field for registration in the This section describes a header field for registration in the
Permanent Message Header Field Registry. [RFC3864] Permanent Message Header Field Registry. [RFC3864]
Header field name Header field name
Sec-WebSocket-Extensions Sec-WebSocket-Extensions
Applicable protocol Applicable protocol
http http
skipping to change at page 55, line 8 skipping to change at page 56, line 8
Author/Change controller Author/Change controller
IETF IETF
Specification document(s) Specification document(s)
RFC XXXX RFC XXXX
Related information Related information
This header field is only used for WebSocket opening handshake. This header field is only used for WebSocket opening handshake.
The |Sec-WebSocket-Extensions| header is used in the WebSocket The |Sec-WebSocket-Extensions| header field is used in the WebSocket
opening handshake. It is initially sent from the client to the opening handshake. It is initially sent from the client to the
server, and then subsequently sent from the server to the client, to server, and then subsequently sent from the server to the client, to
agree on a set of protocol-level extensions to use for the duration agree on a set of protocol-level extensions to use for the duration
of the connection. of the connection.
11.6. WebSocket Extension Name Registry 11.3.3. Sec-WebSocket-Accept
This specification requests the creation of a new IANA registry for
WebSocket Extension names to be used with the WebSocket protocol in
accordance with the principles set out in RFC 5226 [RFC5226].
As part of this registry IANA will maintain the following
information:
Extension Identifier
The identifier of the extension, as will be used in the Sec-
WebSocket-Extension header registered in Section 11.5 of this
specification. The value must conform to the requirements for an
extension-token as defined in Section 9.1 of this specification.
Extension Common Name
The name of the extension, as the extension is generally referred
to.
Extension Definition
A reference to the document in which the extension being used with
the WebSocket protocol is defined.
Known Incompatible Extensions
A list of extension identifiers with which this extension is known
to be incompatible.
WebSocket Extension names are to be subject to "First Come First
Served" IANA registration policy [RFC5226], with the exception of
WebSocket Extension names whose Extension Identifier matches a
private-use-token as defined in Section 9.1 (values beginning with
"x-"). These Extension Identifiers matching private-use-token are
reserved for Experimental Use as per RFC5226 [RFC5226].
IANA is asked to add an initial value to the registry (there are no
known incompatible extensions for this initial entry):
Extension Identifier | Extension Common Name | Extension Definition
-+---------------------+------------------------+-----------------------
| deflate-stream | Deflate Stream | Section 9.2.1 of this
| | Compression | document.
-+---------------------+------------------------+-----------------------
11.7. Sec-WebSocket-Accept
This section describes a header field for registration in the This section describes a header field for registration in the
Permanent Message Header Field Registry. [RFC3864] Permanent Message Header Field Registry. [RFC3864]
Header field name Header field name
Sec-WebSocket-Accept Sec-WebSocket-Accept
Applicable protocol Applicable protocol
http http
skipping to change at page 56, line 34 skipping to change at page 56, line 37
Author/Change controller Author/Change controller
IETF IETF
Specification document(s) Specification document(s)
RFC XXXX RFC XXXX
Related information Related information
This header field is only used for WebSocket opening handshake. This header field is only used for WebSocket opening handshake.
The |Sec-WebSocket-Accept| header is used in the WebSocket opening The |Sec-WebSocket-Accept| header field is used in the WebSocket
handshake. It is sent from the server to the client to confirm that opening handshake. It is sent from the server to the client to
the server is willing to initiate the connection. confirm that the server is willing to initiate the connection.
11.8. Sec-WebSocket-Origin 11.3.4. Sec-WebSocket-Protocol
This section describes a header field for registration in the This section describes a header field for registration in the
Permanent Message Header Field Registry. [RFC3864] Permanent Message Header Field Registry. [RFC3864]
Header field name Header field name
Sec-WebSocket-Origin Sec-WebSocket-Protocol
Applicable protocol Applicable protocol
http http
Status Status
standard standard
Author/Change controller Author/Change controller
IETF IETF
Specification document(s) Specification document(s)
RFC XXXX RFC XXXX
Related information Related information
This header field is only used for WebSocket opening handshake. This header field is only used for WebSocket opening handshake.
The |Sec-WebSocket-Origin| header is used in the WebSocket opening The |Sec-WebSocket-Protocol| header field is used in the WebSocket
handshake. It is sent from the server to the client to confirm the opening handshake. It is sent from the client to the server and back
origin of the script that opened the connection. This enables from the server to the client to confirm the subprotocol of the
clients to verify that the server is willing to serve the script that connection. This enables scripts to both select a subprotocol and be
opened the connection. sure that the server agreed to serve that subprotocol.
11.9. Sec-WebSocket-Protocol 11.3.5. Sec-WebSocket-Version
This section describes a header field for registration in the This section describes a header field for registration in the
Permanent Message Header Field Registry. [RFC3864] Permanent Message Header Field Registry [RFC3864].
Header field name Header field name
Sec-WebSocket-Protocol Sec-WebSocket-Version
Applicable protocol Applicable protocol
http http
Status Status
standard standard
Author/Change controller Author/Change controller
IETF IETF
Specification document(s) Specification document(s)
RFC XXXX RFC XXXX
Related information Related information
This header field is only used for WebSocket opening handshake. This header field is only used for WebSocket opening handshake.
The |Sec-WebSocket-Protocol| header is used in the WebSocket opening The |Sec-WebSocket-Version| header field is used in the WebSocket
handshake. It is sent from the client to the server and back from opening handshake. It is sent from the client to the server to
the server to the client to confirm the subprotocol of the indicate the protocol version of the connection. This enables
connection. This enables scripts to both select a subprotocol and be servers to correctly interpret the opening handshake and subsequent
sure that the server agreed to serve that subprotocol. data being sent from the data, and close the connection if the server
cannot interpret that data in a safe manner. The |Sec-WebSocket-
Version| header field is also sent from the server to the client on
WebSocket handshake error, when the version received from the client
does not match a version understood by the server. In such a case
the header field includes the protocol version(s) supported by the
server.
11.10. WebSocket Subprotocol Name Registry Note that there is no expectation that higher version numbers are
necessarily backward compatible with lower version numbers.
11.4. WebSocket Extension Name Registry
This specification requests the creation of a new IANA registry for
WebSocket Extension names to be used with the WebSocket protocol in
accordance with the principles set out in RFC 5226 [RFC5226].
As part of this registry IANA will maintain the following
information:
Extension Identifier
The identifier of the extension, as will be used in the Sec-
WebSocket-Extension header field registered in Section 11.3.2 of
this specification. The value must conform to the requirements
for an extension-token as defined in Section 9.1 of this
specification.
Extension Common Name
The name of the extension, as the extension is generally referred
to.
Extension Definition
A reference to the document in which the extension being used with
the WebSocket protocol is defined.
Known Incompatible Extensions
A list of extension identifiers with which this extension is known
to be incompatible.
WebSocket Extension names are to be subject to "First Come First
Served" IANA registration policy [RFC5226], with the exception of
WebSocket Extension names whose Extension Identifier matches a
private-use-token as defined in Section 9.1 (values beginning with
"x-"). These Extension Identifiers matching private-use-token are
reserved for Experimental Use as per RFC5226 [RFC5226].
There are no initial values in this registry.
11.5. WebSocket Subprotocol Name Registry
This specification requests the creation of a new IANA registry for This specification requests the creation of a new IANA registry for
WebSocket Subprotocol names to be used with the WebSocket protocol in WebSocket Subprotocol names to be used with the WebSocket protocol in
accordance with the principles set out in RFC 5226 [RFC5226]. accordance with the principles set out in RFC 5226 [RFC5226].
As part of this registry IANA will maintain the following As part of this registry IANA will maintain the following
information: information:
Subprotocol Identifier Subprotocol Identifier
The identifier of the subprotocol, as will be used in the Sec- The identifier of the subprotocol, as will be used in the Sec-
WebSocket-Protocol header registered in Section 11.9 of this WebSocket-Protocol header field registered in Section 11.3.4 of
specification. The value must conform to the requirements given this specification. The value must conform to the requirements
in Paragraph 10 of Section 5.1 of this specification, namely the given in Paragraph 10 of Section 5.1 of this specification, namely
value must be a token as defined by RFC 2616 [RFC2616]. the value must be a token as defined by RFC 2616 [RFC2616].
Subprotocol Common Name Subprotocol Common Name
The name of the subprotocol, as the subprotocol is generally The name of the subprotocol, as the subprotocol is generally
referred to. referred to.
Subprotocol Definition Subprotocol Definition
A reference to the document in which the subprotocol being used A reference to the document in which the subprotocol being used
with the WebSocket protocol is defined. with the WebSocket protocol is defined.
WebSocket Subprotocol names are to be subject to "First Come First WebSocket Subprotocol names are to be subject to "First Come First
Served" IANA registration policy [RFC5226]. Served" IANA registration policy [RFC5226].
11.11. Sec-WebSocket-Version 11.6. WebSocket Version Number Registry
This section describes a header field for registration in the
Permanent Message Header Field Registry. [RFC3864]
Header field name
Sec-WebSocket-Version
Applicable protocol
http
Status
standard
Author/Change controller
IETF
Specification document(s)
RFC XXXX
Related information
This header field is only used for WebSocket opening handshake.
The |Sec-WebSocket-Version| header is used in the WebSocket opening
handshake. It is sent from the client to the server to indicate the
protocol version of the connection. This enables servers to
correctly interpret the opening handshake and subsequent data being
sent from the data, and close the connection if the server cannot
interpret that data in a safe manner.
11.12. WebSocket Version Number Registry
This specification requests the creation of a new IANA registry for This specification requests the creation of a new IANA registry for
WebSocket Version Numbers to be used with the WebSocket protocol in WebSocket Version Numbers to be used with the WebSocket protocol in
accordance with the principles set out in RFC 5226 [RFC5226]. accordance with the principles set out in RFC 5226 [RFC5226].
As part of this registry IANA will maintain the following As part of this registry IANA will maintain the following
information: information:
Version Number Version Number
The version number to be used in the Sec-WebSocket-Version as The version number to be used in the Sec-WebSocket-Version as
specified in Section 5.1 of this specification. The value must be specified in Section 5.1 of this specification. The value must be
a whole number (zero or higher). a non negative integer in the range between 0 and 255 (inclusive).
Reference Reference
The RFC requesting a new version number. The RFC requesting a new version number.
WebSocket Version Numbers are to be subject to "IETF Review" IANA WebSocket Version Numbers are to be subject to "IETF Review" IANA
registration policy [RFC5226]. In order to improve interoperability registration policy [RFC5226]. In order to improve interoperability
with intermediate versions published in Internet Drafts, version with intermediate versions published in Internet Drafts, version
numbers associated with such drafts might be registered in this numbers associated with such drafts might be registered in this
registry. registry. Note that "IETF Review" applies to registrations
corresponding to Internet Drafts.
IANA is asked to add initial values to the registry, with suggested IANA is asked to add initial values to the registry, with suggested
numerical values as these have been used in past versions of this numerical values as these have been used in past versions of this
protocol. protocol.
Version Number | Reference Version Number | Reference
-+----------------+-----------------------------------------+- -+----------------+-----------------------------------------+-
| 0 + draft-ietf-hybi-thewebsocketprotocol-00 | | 0 + draft-ietf-hybi-thewebsocketprotocol-00 |
-+----------------+-----------------------------------------+- -+----------------+-----------------------------------------+-
| 1 + draft-ietf-hybi-thewebsocketprotocol-01 | | 1 + draft-ietf-hybi-thewebsocketprotocol-01 |
skipping to change at page 60, line 25 skipping to change at page 60, line 31
| 4 + draft-ietf-hybi-thewebsocketprotocol-04 | | 4 + draft-ietf-hybi-thewebsocketprotocol-04 |
-+----------------+-----------------------------------------+- -+----------------+-----------------------------------------+-
| 5 + draft-ietf-hybi-thewebsocketprotocol-05 | | 5 + draft-ietf-hybi-thewebsocketprotocol-05 |
-+----------------+-----------------------------------------+- -+----------------+-----------------------------------------+-
| 6 + draft-ietf-hybi-thewebsocketprotocol-06 | | 6 + draft-ietf-hybi-thewebsocketprotocol-06 |
-+----------------+-----------------------------------------+- -+----------------+-----------------------------------------+-
| 7 + draft-ietf-hybi-thewebsocketprotocol-07 | | 7 + draft-ietf-hybi-thewebsocketprotocol-07 |
-+----------------+-----------------------------------------+- -+----------------+-----------------------------------------+-
| 8 + draft-ietf-hybi-thewebsocketprotocol-08 | | 8 + draft-ietf-hybi-thewebsocketprotocol-08 |
-+----------------+-----------------------------------------+- -+----------------+-----------------------------------------+-
| 9 + draft-ietf-hybi-thewebsocketprotocol-09 | | 9 + Reserved |
-+----------------+-----------------------------------------+-
| 10 + Reserved |
-+----------------+-----------------------------------------+-
| 11 + Reserved |
-+----------------+-----------------------------------------+- -+----------------+-----------------------------------------+-
11.13. WebSocket Close Code Number Registry 11.7. WebSocket Close Code Number Registry
This specification requests the creation of a new IANA registry for This specification requests the creation of a new IANA registry for
WebSocket Connection Close Code Numbers in accordance with the WebSocket Connection Close Code Numbers in accordance with the
principles set out in RFC 5226 [RFC5226]. principles set out in RFC 5226 [RFC5226].
As part of this registry IANA will maintain the following As part of this registry IANA will maintain the following
information: information:
Status Code Status Code
The Status Code which denotes a reson for a WebSocket connection The Status Code which denotes a reson for a WebSocket connection
closure as per Section 7.4 of this document. The status code is closure as per Section 7.4 of this document. The status code is
an integer number. an integer number between 1000 and 4999 (inclusive).
Meaning Meaning
The meaning of the status code. The meaning of the status code. Each status code has to have a
unique meaning.
Contact Contact
A contact for the entity reserving the status code. A contact for the entity reserving the status code.
Reference Reference
The stable document requesting the status codes and defining their The stable document requesting the status codes and defining their
meaning, required for status codes in the range 1000-2999. meaning. This is required for status codes in the range 1000-
2999, and recommended for status codes in the range 3000-3999.
WebSocket Close Code Numbers are to be subject to different WebSocket Close Code Numbers are to be subject to different
registration requirements depending on their range. Unless otherwise registration requirements depending on their range. Unless otherwise
specified, requests are subject to "Standards Action" IANA specified, requests are subject to "Standards Action" IANA
registration policy [RFC5226]. Requests for status codes for use by registration policy [RFC5226]. Requests for status codes for use by
this protocol or subsequent versions are subject to Standards Action this protocol, its subsequent versions or extensions are subject to
and should be granted status codes in the range 1000-1999. Requests any one of "Standards Action", "Specification Required" (which
for status codes for use by extensions are subject to Specification implies "Designated Expert") or "IESG Review" IANA registration
Required and should be granted Status Codes in the range 2000-2999. policies and should be granted status codes in the range 1000-2999.
Requests for status codes for use by libraries and frameworks are Requests for status codes for use by libraries, frameworks and
subject to First Come First Served and should be granted in the range applications are subject to "First Come First Served" IANA
3000-3999. The range of status codes from 4000-4999 is designated registration policy and should be granted in the range 3000-3999.
for Private Use by application code. Requests should indicate The range of status codes from 4000-4999 is designated for Private
whether they are requesting status codes for use by the WebSocket Use. Requests should indicate whether they are requesting status
protocol (or a future version of the protocol), by extensions, or by codes for use by the WebSocket protocol (or a future version of the
libraries and frameworks. protocol) or by extensions, or by libraries/frameworks/applications.
IANA is asked to add initial values to the registry, with suggested IANA is asked to add initial values to the registry, with suggested
numerical values as these have been used in past versions of this numerical values as these have been used in past versions of this
protocol. protocol.
|Status Code | Meaning | Contact | Reference | |Status Code | Meaning | Contact | Reference |
-+------------+-----------------+---------------+-----------| -+------------+-----------------+---------------+-----------|
| 1000 | Normal Closure | hybi@ietf.org | RFC XXXX | | 1000 | Normal Closure | hybi@ietf.org | RFC XXXX |
-+------------+-----------------+---------------+-----------| -+------------+-----------------+---------------+-----------|
| 1001 | Going Away | hybi@ietf.org | RFC XXXX | | 1001 | Going Away | hybi@ietf.org | RFC XXXX |
skipping to change at page 61, line 42 skipping to change at page 62, line 24
-+------------+-----------------+---------------+-----------| -+------------+-----------------+---------------+-----------|
| 1004 | Frame Too Large | hybi@ietf.org | RFC XXXX | | 1004 | Frame Too Large | hybi@ietf.org | RFC XXXX |
-+------------+-----------------+---------------+-----------| -+------------+-----------------+---------------+-----------|
| 1005 | No Status Rcvd | hybi@ietf.org | RFC XXXX | | 1005 | No Status Rcvd | hybi@ietf.org | RFC XXXX |
-+------------+-----------------+---------------+-----------| -+------------+-----------------+---------------+-----------|
| 1006 | Abnormal Closure| hybi@ietf.org | RFC XXXX | | 1006 | Abnormal Closure| hybi@ietf.org | RFC XXXX |
-+------------+-----------------+---------------+-----------| -+------------+-----------------+---------------+-----------|
| 1007 | Invalid UTF-8 | hybi@ietf.org | RFC XXXX | | 1007 | Invalid UTF-8 | hybi@ietf.org | RFC XXXX |
-+------------+-----------------+---------------+-----------| -+------------+-----------------+---------------+-----------|
11.14. WebSocket Opcode Registry 11.8. WebSocket Opcode Registry
This specification requests the creation of a new IANA registry for This specification requests the creation of a new IANA registry for
WebSocket Opcodes in accordance with the principles set out in RFC WebSocket Opcodes in accordance with the principles set out in RFC
5226 [RFC5226]. 5226 [RFC5226].
As part of this registry IANA will maintain the following As part of this registry IANA will maintain the following
information: information:
Opcode Opcode
The opcode denotes the frame type of the WebSocket frame, as The opcode denotes the frame type of the WebSocket frame, as
skipping to change at page 62, line 38 skipping to change at page 63, line 20
-+--------+-------------------------------------+-----------| -+--------+-------------------------------------+-----------|
| 2 | Binary Frame | RFC XXXX | | 2 | Binary Frame | RFC XXXX |
-+--------+-------------------------------------+-----------| -+--------+-------------------------------------+-----------|
| 8 | Connection Close Frame | RFC XXXX | | 8 | Connection Close Frame | RFC XXXX |
-+--------+-------------------------------------+-----------| -+--------+-------------------------------------+-----------|
| 9 | Ping Frame | RFC XXXX | | 9 | Ping Frame | RFC XXXX |
-+--------+-------------------------------------+-----------| -+--------+-------------------------------------+-----------|
| 10 | Pong Frame | RFC XXXX | | 10 | Pong Frame | RFC XXXX |
-+--------+-------------------------------------+-----------| -+--------+-------------------------------------+-----------|
11.15. WebSocket Framing Header Bits Registry 11.9. WebSocket Framing Header Bits Registry
This specification requests the creation of a new IANA registry for This specification requests the creation of a new IANA registry for
WebSocket Framing Header Bits in accordance with the principles set WebSocket Framing Header Bits in accordance with the principles set
out in RFC 5226 [RFC5226]. This registry controls assignment of the out in RFC 5226 [RFC5226]. This registry controls assignment of the
bits marked RSV1, RSV2, and RSV3 in Section 4.2. bits marked RSV1, RSV2, and RSV3 in Section 4.2.
These bits are reserved for future versions or extensions of this These bits are reserved for future versions or extensions of this
specification. specification.
WebSocket Framing Header Bits assignments are subject to "Standards WebSocket Framing Header Bits assignments are subject to "Standards
skipping to change at page 65, line 5 skipping to change at page 65, line 22
specification is given in the WHATWG HTML specification at specification is given in the WHATWG HTML specification at
http://whatwg.org/html5. http://whatwg.org/html5.
Special thanks also to John Tamplin for providing a significant Special thanks also to John Tamplin for providing a significant
amount of text for the Data Framing section of this specification. amount of text for the Data Framing section of this specification.
Special thanks also to Adam Barth for providing a significant amount Special thanks also to Adam Barth for providing a significant amount
of text and background research for the Data Masking section of this of text and background research for the Data Masking section of this
specification. specification.
Special thanks to Lisa Dusseault for the Apps Area review (and for
helping to start this work), Richard Barnes for the Gen-Art review
and Magnus Westerlund for the Transport Area Review. Special thanks
to HYBI WG past and present WG chairs who tirelessly worked behind
the scene to move this work toward completion: Joe Hildebrand,
Salvatore Loreto and Gabriel Montenegro. And last but not least,
special thank you to the responsible Area Director Peter Saint-Andre.
Thank you to the following people who participated in discussions on
the HYBI WG mailing list and contributed ideas and/or provided
detailed reviews (the list is likely to be incomplete): Greg Wilkins,
John Tamplin, Willy Tarreau, Maciej Stachowiak, Jamie Lokier, Scott
Ferguson, Bjoern Hoehrmann, Julian Reschke, Dave Cridland, Andy
Green, Eric Rescorla, Inaki Baz Castillo, Martin Thomson, Roberto
Peon, Patrick McManus, Zhong Yu, Bruce Atherton, Takeshi Yoshino,
Martin J. Duerst, James Graham, Simon Pieters, Roy T. Fielding,
Mykyta Yevstifeyev. Note that people listed above didn't necessarily
endorsed the end result of this work.
14. References 14. References
14.1. Normative References 14.1. Normative References
[ANSI.X3-4.1986] [ANSI.X3-4.1986]
American National Standards Institute, "Coded Character American National Standards Institute, "Coded Character
Set - 7-bit American Standard Code for Information Set - 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
[FIPS.180-2.2002] [FIPS.180-2.2002]
National Institute of Standards and Technology, "Secure National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-2, August 2002, <http:// Hash Standard", FIPS PUB 180-2, August 2002, <http://
csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf>. csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf>.
[RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and
L. Jones, "SOCKS Protocol Version 5", RFC 1928, L. Jones, "SOCKS Protocol Version 5", RFC 1928,
March 1996. March 1996.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, May 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
HTTP/1.1", RFC 2817, May 2000. HTTP/1.1", RFC 2817, May 2000.
skipping to change at page 66, line 29 skipping to change at page 67, line 26
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[I-D.ietf-websec-origin] [I-D.ietf-websec-origin]
Barth, A., "The Web Origin Concept", Barth, A., "The Web Origin Concept",
draft-ietf-websec-origin-00 (work in progress), draft-ietf-websec-origin-02 (work in progress), June 2011.
December 2010.
14.2. Informative References 14.2. Informative References
[WSAPI] Hickson, I., "The Web Sockets API", August 2010, [WSAPI] Hickson, I., "The Web Sockets API", August 2010,
<http://dev.w3.org/html5/websockets/>. <http://dev.w3.org/html5/websockets/>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122,
July 2005.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011. April 2011.
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, May 1996.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008. October 2008.
[RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins, [RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins,
"Known Issues and Best Practices for the Use of Long "Known Issues and Best Practices for the Use of Long
Polling and Streaming in Bidirectional HTTP", RFC 6202, Polling and Streaming in Bidirectional HTTP", RFC 6202,
April 2011. April 2011.
[W3C.REC-wsc-ui-20100812] [W3C.REC-wsc-ui-20100812]
Roessler, T. and A. Saldhana, "Web Security Context: User Saldhana, A. and T. Roessler, "Web Security Context: User
Interface Guidelines", World Wide Web Consortium Interface Guidelines", World Wide Web Consortium
Recommendation REC-wsc-ui-20100812, August 2010, Recommendation REC-wsc-ui-20100812, August 2010,
<http://www.w3.org/TR/2010/REC-wsc-ui-20100812>. <http://www.w3.org/TR/2010/REC-wsc-ui-20100812>.
Authors' Addresses Authors' Addresses
Ian Fette Ian Fette
Google, Inc. Google, Inc.
Email: ifette+ietf@google.com Email: ifette+ietf@google.com
 End of changes. 141 change blocks. 
508 lines changed or deleted 535 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
X-Generator: pyht 0.35