draft-ietf-hybi-thewebsocketprotocol-04.txt   draft-ietf-hybi-thewebsocketprotocol-05.txt 
HyBi Working Group I. Fette HyBi Working Group I. Fette
Internet-Draft Google, Inc. Internet-Draft Google, Inc.
Intended status: Standards Track January 11, 2011 Intended status: Standards Track February 8, 2011
Expires: July 15, 2011 Expires: August 12, 2011
The WebSocket protocol The WebSocket protocol
draft-ietf-hybi-thewebsocketprotocol-04 draft-ietf-hybi-thewebsocketprotocol-05
Abstract Abstract
The WebSocket protocol enables two-way communication between a user The WebSocket protocol enables two-way communication between a user
agent running untrusted code running in a controlled environment to a agent 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 initial commonly used by Web browsers. The protocol consists of an initial
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 41 skipping to change at page 1, line 41
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 July 15, 2011. This Internet-Draft will expire on August 12, 2011.
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
skipping to change at page 2, line 30 skipping to change at page 2, line 30
1.6. Security model . . . . . . . . . . . . . . . . . . . . . . 9 1.6. Security model . . . . . . . . . . . . . . . . . . . . . . 9
1.7. Relationship to TCP and HTTP . . . . . . . . . . . . . . . 10 1.7. Relationship to TCP and HTTP . . . . . . . . . . . . . . . 10
1.8. Establishing a connection . . . . . . . . . . . . . . . . 10 1.8. Establishing a connection . . . . . . . . . . . . . . . . 10
1.9. Subprotocols using the WebSocket protocol . . . . . . . . 11 1.9. Subprotocols using the WebSocket protocol . . . . . . . . 11
2. Conformance requirements . . . . . . . . . . . . . . . . . . . 12 2. Conformance requirements . . . . . . . . . . . . . . . . . . . 12
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 12 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 12
3. WebSocket URLs . . . . . . . . . . . . . . . . . . . . . . . . 14 3. WebSocket URLs . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1. Parsing WebSocket URLs . . . . . . . . . . . . . . . . . . 14 3.1. Parsing WebSocket URLs . . . . . . . . . . . . . . . . . . 14
3.2. Constructing WebSocket URLs . . . . . . . . . . . . . . . 15 3.2. Constructing WebSocket URLs . . . . . . . . . . . . . . . 15
3.3. Valid WebSocket URLs . . . . . . . . . . . . . . . . . . . 15 3.3. Valid WebSocket URLs . . . . . . . . . . . . . . . . . . . 15
4. Data Framing . . . . . . . . . . . . . . . . . . . . . . . . . 17 4. Data Framing . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2. Client-to-Server Masking . . . . . . . . . . . . . . . . . 17 4.2. Client-to-Server Masking . . . . . . . . . . . . . . . . . 16
4.3. Base Framing Protocol . . . . . . . . . . . . . . . . . . 18 4.3. Base Framing Protocol . . . . . . . . . . . . . . . . . . 17
4.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 21 4.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 19
4.5. Control Frames . . . . . . . . . . . . . . . . . . . . . . 22 4.5. Control Frames . . . . . . . . . . . . . . . . . . . . . . 20
4.5.1. Close . . . . . . . . . . . . . . . . . . . . . . . . 22 4.5.1. Close . . . . . . . . . . . . . . . . . . . . . . . . 20
4.5.2. Ping . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.5.2. Ping . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.5.3. Pong . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.5.3. Pong . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.6. Data Frames . . . . . . . . . . . . . . . . . . . . . . . 23 4.6. Data Frames . . . . . . . . . . . . . . . . . . . . . . . 21
4.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 24 4.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 22
5. Opening Handshake . . . . . . . . . . . . . . . . . . . . . . 25 5. Opening Handshake . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Client Requirements . . . . . . . . . . . . . . . . . . . 25 5.1. Client Requirements . . . . . . . . . . . . . . . . . . . 24
5.2. Server-side requirements . . . . . . . . . . . . . . . . . 29 5.2. Server-side requirements . . . . . . . . . . . . . . . . . 28
5.2.1. Reading the client's opening handshake . . . . . . . . 29 5.2.1. Reading the client's opening handshake . . . . . . . . 29
5.2.2. Sending the server's opening handshake . . . . . . . . 30 5.2.2. Sending the server's opening handshake . . . . . . . . 29
6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 33 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 33
6.1. Handling errors in UTF-8 from the server . . . . . . . . . 33 6.1. Handling errors in UTF-8 from the server . . . . . . . . . 33
6.2. Handling errors in UTF-8 from the client . . . . . . . . . 33 6.2. Handling errors in UTF-8 from the client . . . . . . . . . 33
7. Closing the connection . . . . . . . . . . . . . . . . . . . . 34 7. Closing the connection . . . . . . . . . . . . . . . . . . . . 34
7.1. Client-initiated closure . . . . . . . . . . . . . . . . . 34 7.1. Abnormal closures . . . . . . . . . . . . . . . . . . . . 34
7.2. Server-initiated closure . . . . . . . . . . . . . . . . . 34 7.1.1. Client-initiated closure . . . . . . . . . . . . . . . 34
7.3. Closure . . . . . . . . . . . . . . . . . . . . . . . . . 34 7.1.2. Server-initiated closure . . . . . . . . . . . . . . . 34
8. Known extensions . . . . . . . . . . . . . . . . . . . . . . . 36 7.2. Normal closure of connections . . . . . . . . . . . . . . 34
8.1. Compression . . . . . . . . . . . . . . . . . . . . . . . 36 8. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 36
9. Security considerations . . . . . . . . . . . . . . . . . . . 37 8.1. Negotiating extensions . . . . . . . . . . . . . . . . . . 36
10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 38 8.2. Known extensions . . . . . . . . . . . . . . . . . . . . . 37
10.1. Registration of ws: scheme . . . . . . . . . . . . . . . . 38 8.2.1. Compression . . . . . . . . . . . . . . . . . . . . . 37
10.2. Registration of wss: scheme . . . . . . . . . . . . . . . 39 9. Security considerations . . . . . . . . . . . . . . . . . . . 39
10.3. Registration of the "WebSocket" HTTP Upgrade keyword . . . 40 10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 40
10.4. Sec-WebSocket-Key and Sec-WebSocket-Nonce . . . . . . . . 40 10.1. Registration of ws: scheme . . . . . . . . . . . . . . . . 40
10.5. Sec-WebSocket-Location . . . . . . . . . . . . . . . . . . 41 10.2. Registration of wss: scheme . . . . . . . . . . . . . . . 41
10.6. Sec-WebSocket-Origin . . . . . . . . . . . . . . . . . . . 42 10.3. Registration of the "WebSocket" HTTP Upgrade keyword . . . 42
10.7. Sec-WebSocket-Protocol . . . . . . . . . . . . . . . . . . 43 10.4. Sec-WebSocket-Key and Sec-WebSocket-Nonce . . . . . . . . 42
10.8. Sec-WebSocket-Version . . . . . . . . . . . . . . . . . . 43 10.5. Sec-WebSocket-Extensions . . . . . . . . . . . . . . . . . 43
11. Using the WebSocket protocol from other specifications . . . . 45 10.6. Sec-WebSocket-Accept . . . . . . . . . . . . . . . . . . . 44
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 46 10.7. Sec-WebSocket-Origin . . . . . . . . . . . . . . . . . . . 45
13. Normative References . . . . . . . . . . . . . . . . . . . . . 47 10.8. Sec-WebSocket-Protocol . . . . . . . . . . . . . . . . . . 45
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 49 10.9. Sec-WebSocket-Version . . . . . . . . . . . . . . . . . . 46
11. Using the WebSocket protocol from other specifications . . . . 47
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 48
13. Normative References . . . . . . . . . . . . . . . . . . . . . 49
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 51
1. Introduction 1. Introduction
1.1. Background 1.1. Background
_This section is non-normative._ _This section is non-normative._
Historically, creating an instant messenger chat client as a Web Historically, creating an instant messenger chat client as a Web
application has required an abuse of HTTP to poll the server for application has required an abuse of HTTP to poll the server for
updates while sending upstream notifications as distinct HTTP calls. updates while sending upstream notifications as distinct HTTP calls.
skipping to change at page 5, line 4 skipping to change at page 5, line 4
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 Sec-WebSocket-Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 4 Sec-WebSocket-Version: 5
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: me89jWimTRKTWwrS3aRrL53YZSo= Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Nonce: AQIDBAUGBwgJCgsMDQ4PEC== Sec-WebSocket-Nonce: AQIDBAUGBwgJCgsMDQ4PEC==
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 After the leading line in both cases come an unordered set of
headers. The meaning of these headers is specified in Section 5 of headers. The meaning of these headers is specified in Section 5 of
this document. Additional headers may also be present, such as this document. Additional headers may also be present, such as
skipping to change at page 6, line 25 skipping to change at page 6, line 25
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 Sec-WebSocket-Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 4 Sec-WebSocket-Version: 5
Headers in the handshake are sent by the client in a random order; Headers in the handshake are sent by the client in a random order;
the order is not meaningful. the order is not meaningful.
Additional headers are used to select options in the WebSocket Additional headers 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|, and |Cookie|, which can used for
sending cookies to the server (e.g. as an authentication mechanism). sending cookies to the server (e.g. as an authentication mechanism).
The |Sec-WebSocket-Protocol| request-header field can be used to The |Sec-WebSocket-Protocol| request-header field can be used to
indicate what subprotocols (application-level protocols layered over indicate what subprotocols (application-level protocols layered over
skipping to change at page 7, line 8 skipping to change at page 7, line 8
The client includes the hostname in the Host header of its handshake The client includes the hostname in the Host header of its handshake
as per [RFC2616], so that both the client and the server can verify as per [RFC2616], so that both the client and the server can verify
that they agree on which host is in use. that they agree on which host is in use.
The |Sec-WebSocket-Origin| header is used to protect against The |Sec-WebSocket-Origin| header is used to protect against
unauthorized cross-origin use of a WebSocket server by scripts using unauthorized cross-origin use of a WebSocket server by scripts using
the |WebSocket| API in a Web browser. The server is informed of the the |WebSocket| API in a Web browser. The server is informed of the
script origin generating the WebSocket connection request. If the script origin generating the WebSocket connection request. If the
server does not wish to accept connections from this origin, it can server does not wish to accept connections from this origin, it can
choose to abort the connection. choose to abort the connection. This header is sent by browser
clients, for non-browser clients this header may be sent if it makes
sense in the context of those clients.
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 in the
skipping to change at page 7, line 39 skipping to change at page 7, line 41
[FIPS.180-2.2002]. [FIPS.180-2.2002].
Concretely, if as in the example above, header |Sec-WebSocket-Key| Concretely, if as in the example above, header |Sec-WebSocket-Key|
had the value "dGhlIHNhbXBsZSBub25jZQ==", the server would 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, to give the value "s3pPLMBiTxaQ9kYGzzhZRbK+ then base64-encoded, to give the value "s3pPLMBiTxaQ9kYGzzhZRbK+
xOo=". xOo=". This value would then be echoed in the header |Sec-WebSocket-
Accept|.
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 must be treated as a failure and the Any status code other than 101 must be treated as a failure and the
websocket connection aborted. The headers follow the status code. websocket connection aborted. The headers follow the status code.
skipping to change at page 8, line 4 skipping to change at page 8, line 7
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 must be treated as a failure and the Any status code other than 101 must be treated as a failure and the
websocket connection aborted. The headers follow the status code. websocket connection aborted. The headers follow the status code.
The |Connection| and |Upgrade| headers complete the HTTP Upgrade. The |Connection| and |Upgrade| headers complete the HTTP Upgrade.
The |Sec-WebSocket-Accept| header indicates whether the server is The |Sec-WebSocket-Accept| header indicates whether the server is
willing to accept the connection. If present, this header must willing to accept the connection. If present, this header must
include a hash of the client's nonce sent in |Sec-WebSocket-Key| include a hash of the client's nonce sent in |Sec-WebSocket-Key|
along with a predefined GUID. Any other value must not be along with a predefined GUID. Any other value must not be
interpreted as an acceptance of the connection by the server. 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: me89jWimTRKTWwrS3aRrL53YZSo= 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 is missing,
or if the HTTP status code is not 101, the connection will not be or if the HTTP status code is not 101, the connection will not be
established and WebSockets frames will not be sent. established and WebSockets 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
skipping to change at page 9, line 38 skipping to change at page 9, line 41
framing mechanism on top of TCP to get back to the IP packet framing mechanism on top of TCP to get back to the IP packet
mechanism that TCP is built on, but without length limits; and re- mechanism that TCP is built on, but without length limits; and re-
implements the closing handshake in-band. Other than that, it adds implements the closing handshake in-band. Other than that, it adds
nothing. Basically it is intended to be as close to just exposing nothing. Basically it is intended to be as close to just exposing
raw TCP to script as possible given the constraints of the Web. It's raw TCP to script as possible given the constraints of the Web. It's
also designed in such a way that its servers can share a port with also designed in such a way that its servers can share a port with
HTTP servers, by having its handshake be a valid HTTP Upgrade HTTP servers, by having its handshake be a valid HTTP Upgrade
handshake also. handshake also.
The protocol is intended to be extensible; future versions will The protocol is intended to be extensible; future versions will
likely introduce a mechanism to compress data and might support likely introduce additional concepts such as multiplexing and
sending binary data. compression.
1.6. Security model 1.6. Security model
_This section is non-normative._ _This section is non-normative._
The WebSocket protocol uses the origin model used by Web browsers to The WebSocket protocol uses the origin model used by Web browsers to
restrict which Web pages can contact a WebSocket server when the restrict which Web pages can contact a WebSocket server when the
WebSocket protocol is used from a Web page. Naturally, when the WebSocket protocol is used from a Web page. Naturally, when the
WebSocket protocol is used by a dedicated client directly (i.e. not WebSocket protocol is used by a dedicated client directly (i.e. not
from a Web page through a Web browser), the origin model is not from a Web page through a Web browser), the origin model is not
skipping to change at page 15, line 36 skipping to change at page 15, line 36
3.3. Valid WebSocket URLs 3.3. Valid WebSocket URLs
For a WebSocket URL to be considered valid, the following conditions For a WebSocket URL to be considered valid, the following conditions
MUST hold. MUST hold.
o The /host/ must be ASCII-only (i.e. it must have been punycode- o The /host/ must be ASCII-only (i.e. it must have been punycode-
encoded already if necessary, and MUST NOT contain any characters encoded already if necessary, and MUST NOT contain any characters
above U+007E). above U+007E).
o The /origin/ must not contain characters in the range U+0041 to
U+005A (i.e. LATIN CAPITAL LETTER A to LATIN CAPITAL LETTER Z).
o The /resource name/ string must be a non-empty string of o The /resource name/ string must be a non-empty string of
characters in the range U+0021 to U+007E that starts with a U+002F characters in the range U+0021 to U+007E that starts with a U+002F
SOLIDUS character (/). SOLIDUS character (/).
o The various strings in /protocols/ MUST all be non-empty strings
with characters in the range U+0021 to U+007E and MUST all be
unique.
Any WebSocket URLs not meeting the above criteria are considered Any WebSocket URLs not meeting the above criteria are considered
invalid, and a client MUST NOT attempt to make a connection to an invalid, and a client MUST NOT attempt to make a connection to an
invalid WebSocket URL. A client SHOULD attempt to parse a URL invalid WebSocket URL. A client SHOULD attempt to parse a URL
obtained from any external source (such as a web site or a user) obtained from any external source (such as a web site or a user)
using the steps specified in Section 3.1 to obtain a valid WebSocket using the steps specified in Section 3.1 to obtain a valid WebSocket
URL, but MUST NOT attempt to connect with such an unparsed URL, and URL, but MUST NOT attempt to connect with such an unparsed URL, and
instead only use the parsed version and only if that version is instead only use the parsed version and only if that version is
considered valid by the criteria above. considered valid by the criteria above.
4. Data Framing 4. Data Framing
skipping to change at page 17, line 30 skipping to change at page 16, line 30
opcode values MUST NOT be used. opcode values MUST NOT be used.
A data frame MAY be transmitted by either the client or the server at A data frame MAY be transmitted by either the client or the server at
any time after handshake completion and before that host has any time after handshake completion and before that host has
generated a close message (Section 4.5.1). generated a close message (Section 4.5.1).
4.2. Client-to-Server Masking 4.2. Client-to-Server Masking
The client MUST mask all frames sent to the server. The client MUST mask all frames sent to the server.
The masking-key is derived from information exchanged between the The masking-key is contained completely within the frame.
client and the server in the handshake and is constant for the
duration of the WebSocket connection.
The masking-key is the SHA-1 hash of the concatenation of the value
of the Sec-WebSocket-Key header (sent from the client to the server),
the value of the Sec-WebSocket-Nonce header (sent from the server to
the client), and the string "61AC5F19-FBBA-4540-B96F-6561F1AB40A8"
(which is unique to the web socket protocol).
For example, if the Sec-WebSocket-Key header contains the value The masking-key is a 32-bit value chosen at random by the client.
"dGhlIHNhbXBsZSBub25jZQ==" and the Sec-WebSocket-Nonce header The masking-key MUST be derived from a strong source of entropy, and
contains the value "AQIDBAUGBwgJCgsMDQ4PEC==", the masking key is the the masking-key for a given frame MUST NOT make it simple for a
SHA-1 hash of the string "dGhlIHNhbXBsZSBub25jZQ==AQIDBAUGBwgJCgsMDQ4 server to predict the masking-key for a subsequent frame.
PEC==61AC5F19-FBBA-4540-B96F-6561F1AB40A8", which is the sequence of
octets 0x41 0xe1 0x4f 0x78 0x31 0x1e 0x4c 0x34 0x28 0x3e 0x6d 0x8b
0x36 0x3b 0x88 0x48 0xd5 0x85 0x91 0xa7.
Each masked frame consists of a 32-bit masking-nonce followed by Each masked frame consists of a 32-bit masking-key followed by
masked-data: masked-data:
masked-frame = masking-nonce masked-data masked-frame = masking-key masked-data
masking-nonce = 4full-octet masking-key = 4full-octet
masked-data = *full-octet masked-data = *full-octet
full-octet = %x00-FF full-octet = %x00-FF
The masked-data is the clear-text frame "encrypted" using a simple The masked-data is the clear-text frame "encrypted" using a simple
XOR cipher as follows. XOR cipher as follows.
1. Let the frame-key be the SHA-1 hash of the concatentation of the Octet i of the masked-data is the XOR of octet i of the clear text
masking-nonce followed by the masking-key. frame with octet i modulo 4 of the masking-key:
2. Octet i of the masked-data is the XOR of octet i of the clear
text frame with octet i modulo 20 of the frame-key:
frame-key = SHA-1(masking-nonce || masking-key) j = i MOD 4
j = i MOD 20 masked-octet-i = clear-text-octet-i XOR octet-j-of-masking-key
masked-octet-i = clear-text-octet-i XOR octet-j-of-frame-key
When preparing a masked-frame, the client MUST pick a fresh masking- When preparing a masked-frame, the client MUST pick a fresh masking-
nonce uniformly at random from the set of allowed 32-bit values. The key uniformly at random from the set of allowed 32-bit values. The
unpredictability of the masking-nonce is essential to prevent the unpredictability of the masking-nonce is essential to prevent the
author of malicious application data from selecting the bytes that author of malicious application data from selecting the bytes that
appear on the wire. appear on the wire.
4.3. Base Framing Protocol 4.3. Base Framing Protocol
This wire format for the data transfer part is described by the ABNF This wire format for the data transfer part is described by the ABNF
given in detail in this section. A high level overview of the given in detail in this section. A high level overview of the
framing is given in the following figure. [RFC5234] framing is given in the following figure. [RFC5234]
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-------+-+-------------+-------------------------------+ +-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|R| Payload len | Extended payload length | |F|R|R|R| opcode|R| Payload len | Extended payload length |
|I|S|S|S| (4) |S| (7) | (16/63) | |I|S|S|S| (4) |S| (7) | (16/63) |
|N|V|V|V| |V| | (if payload len==126/127) | |N|V|V|V| |V| | (if payload len==126/127) |
| |1|2|3| |4| | | | |1|2|3| |4| | |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - + +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
| Extended payload length continued, if payload len == 127 | | Extended payload length continued, if payload len == 127 |
+ - - - - - - - - - - - - - - - +-------------------------------+ + - - - - - - - - - - - - - - - +-------------------------------+
skipping to change at page 21, line 5 skipping to change at page 19, line 5
Application data: n bytes Application data: n bytes
Arbitrary application data, taking up the remainder of the frame Arbitrary application data, taking up the remainder of the frame
after any extension data. The length of the Application data is after any extension data. The length of the Application data is
equal to the payload length minus the length of the Extension equal to the payload length minus the length of the Extension
data. data.
The base framing protocol is formally defined by the following ABNF The base framing protocol is formally defined by the following ABNF
[RFC5234]: [RFC5234]:
ws-frame = frame-more ws-frame = frame-fin
frame-rsv1 frame-rsv1
frame-rsv2 frame-rsv2
frame-rsv3 frame-rsv3
frame-opcode frame-opcode
frame-rsv4 frame-rsv4
frame-length frame-length
frame-extension frame-extension
application-data; application-data;
frame-more = %x0 ; final frame of message frame-fin = %x0 ; more frames of this message follow
/ %x1 ; more frames of this message follow / %x1 ; final frame of message
frame-rsv1 = %x0 ; 1 bit, must be 0 frame-rsv1 = %x0 ; 1 bit, must be 0
frame-rsv2 = %x0 ; 1 bit, must be 0 frame-rsv2 = %x0 ; 1 bit, must be 0
frame-rsv3 = %x0 ; 1 bit, must be 0 frame-rsv3 = %x0 ; 1 bit, must be 0
frame-opcode = %x0 ; continuation frame frame-opcode = %x0 ; continuation frame
/ %x1 ; connection close / %x1 ; connection close
/ %x2 ; ping / %x2 ; ping
skipping to change at page 22, line 40 skipping to change at page 20, line 40
(Pong). Control frames are used to communicate state about the (Pong). Control frames are used to communicate state about the
websocket. websocket.
All control frames MUST be 125 bytes or less in length and MUST NOT All control frames MUST be 125 bytes or less in length and MUST NOT
be fragmented. be fragmented.
4.5.1. Close 4.5.1. Close
The Close message contains an opcode of 0x01. The Close message contains an opcode of 0x01.
The Close message contains a body that is at least one byte in
length. If the close is initiated by the client, the first byte of
the body MUST be a 0x43. If the close is initiated by the server,
the first byte of the body MUST be a 0x53. The body MAY contain
additional bytes, the meaning of those bytes are not defined by this
version of the protocol.
The application MUST NOT send any more data messages after sending a The application MUST NOT send any more data messages after sending a
close message. close message.
A received close message is deemed to be an acknowledgement if the A received close message is deemed to be an acknowledgement if the
message body matches the body of a close message previously sent by message body matches the body of a close message previously sent by
the receiver. Otherwise the close message is a close initiated by the receiver.
the sender.
Upon receipt of an initiated close the endpoint MUST send a close Upon receipt of an initiated close the endpoint MUST send a close
acknowledgment. It should do so as soon as is practical. acknowledgment. It should do so as soon as is practical. The body
of the acknowledgement must match the body of the close message
received.
The websocket is considered fully closed when an endpoint has either The websocket is considered fully closed when an endpoint has either
received a close acknowledgment or sent a close acknowledgment. received a close acknowledgment or sent a close acknowledgment.
To prevent a situation where ambiguity arises from a client and
server both sending a close frame at approximately the same time, the
close frame has a body that can be used to distinguish whether a
close frame is an initiation of a close event or the acknowledgement
of the other side's close. (Without resolving the ambiguity, a party
has no way of knowing whether its last bytes before the close frame
were received).
4.5.2. Ping 4.5.2. Ping
The Ping message contains an opcode of 0x02. The Ping message contains an opcode of 0x02.
Upon receipt of a Ping message, an endpoint MUST send a Pong message Upon receipt of a Ping message, an endpoint MUST send a Pong message
in response. It SHOULD do so as soon as is practical. The message in response. It SHOULD do so as soon as is practical. The message
bodies of the Ping and Pong MUST be the same. bodies of the Ping and Pong MUST be the same.
4.5.3. Pong 4.5.3. Pong
The Pong message contains an opcode of 0x03. The Pong message contains an opcode of 0x03.
Upon receipt of a Ping message, an endpoint MUST send a Pong message Upon receipt of a Ping message, an endpoint MUST send a Pong message
in response. It SHOULD do so as soon as is practical. The message in response. It SHOULD do so as soon as is practical. The message
bodies of the Ping and Pong MUST be the same. bodies of the Ping and Pong MUST be the same. A Pong is issued only
in response to the most recent Ping.
4.6. Data Frames 4.6. Data Frames
All frame types not listed in Section 4.5 are data frames, which All frame types not listed in Section 4.5 are data frames, which
transport application-layer data. The opcode determines the transport application-layer data. The opcode determines the
interpretation of the application data: interpretation of the application data:
Text Text
The payload data is text data encoded as UTF-8. The payload data is text data encoded as UTF-8.
skipping to change at page 23, line 42 skipping to change at page 22, line 11
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._
o A single-frame text message o A single-frame text message
* 0x04 0x05 "Hello" * 0x84 0x05 0x48 0x65 0x6c 0x6c 0x6f (contains "Hello")
o A fragmented text message o A fragmented text message
* 0x84 0x03 "Hel" * 0x04 0x03 0x48 0x65 0x6c (contains "Hel")
* 0x00 0x02 "lo" * 0x80 0x02 0x6c 0x6f (contains "lo")
o Ping request and response o Ping request and response
* 0x02 0x05 "Hello"
* 0x03 0x05 "Hello" * 0x82 0x05 0x48 0x65 0x6c 0x6c 0x6f (contains a body of "Hello",
but the contents of the body are arbitrary)
* 0x83 0x05 0x48 0x65 0x6c 0x6c 0x6f (contains a body of "Hello",
matching the body of the ping)
o 256 bytes binary message in a single frame o 256 bytes binary message in a single frame
* 0x05 0x7E 0x0100 [256 bytes of binary data] * 0x85 0x7E 0x0100 [256 bytes of binary data]
o 64KiB binary message in a single frame o 64KiB binary message in a single frame
* 0x05 0x7F 0x0000000000010000 [65536 bytes of binary data] * 0x85 0x7F 0x0000000000010000 [65536 bytes of binary data]
4.8. Extensibility 4.8. Extensibility
The protocol is designed to allow for extensions, which will add The protocol is designed to allow for extensions, which will add
capabilities to the base protocols. The endpoints of a connection capabilities to the base protocols. The endpoints of a connection
MUST negotiate the use of any extensions during the handshake. This MUST negotiate the use of any extensions during the handshake. This
specification provides opcodes 0x6 through 0xF, the extension data specification provides opcodes 0x6 through 0xF, the extension data
field, and the frame-rsv1, frame-rsv2, frame-rsv3, and frame-rsv4 field, and the frame-rsv1, frame-rsv2, frame-rsv3, and frame-rsv4
bits of the frame header for use by extensions. Below are some bits of the frame header for use by extensions. The negotiation of
anticipated uses of extensions. This list is neither complete nor extensions is discussed in further detail in Section 8.1. Below are
proscriptive. some anticipated uses of extensions. This list is neither complete
nor proscriptive.
o Extension data may be placed in the payload before the application o Extension data may be placed in the payload before the application
data. data.
o Reserved bits can be allocated for per-frame needs. o Reserved bits can be allocated for per-frame needs.
o Reserved opcode values can be defined. o Reserved opcode values can be defined.
o Reserved bits can be allocated to the opcode field if more opcode o Reserved bits can be allocated to the opcode field if more opcode
values are needed. values are needed.
skipping to change at page 28, line 6 skipping to change at page 27, line 6
randomly selected 16-byte value that has been base64-encoded randomly selected 16-byte value that has been base64-encoded
[RFC3548]. The nonce MUST be randomly selected randomly for [RFC3548]. The nonce MUST be randomly selected randomly for
each connection. 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==" would be "AQIDBAUGBwgJCgsMDQ4PEC=="
8. The request MUST include a header with the name "Sec-WebSocket- 8. The request MUST include a header with the name "Sec-WebSocket-
Origin". The value of this header MUST be the ASCII Origin" if the request is coming from a browser client. If the
serialization of origin of the context in which the code connection is from a non-browser client, the request MAY include
establishing the connection is running [I-D.ietf-websec-origin]. this header if the semantics of that client match the use-case
described here for browser clients. The value of this header
MUST be the ASCII serialization of origin of the context in
which the code establishing the connection is running, and MUST
be lower-case. The value MUST NOT contain letters in the range
U+0041 to U+005A (i.e. LATIN CAPITAL LETTER A to LATIN CAPITAL
LETTER Z) [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 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 with the name "Sec-WebSocket-
Version". The value of this header must be 4. Version". The value of this header must be 5.
10. The request MAY include a header with the name "Sec-WebSocket- 10. The request MAY include a header with the name "Sec-WebSocket-
Protocol". If present, this value indicates the subprotocol(s) Protocol". If present, this value indicates the subprotocol(s)
the client wishes to speak. The ABNF for the value of this the client wishes to speak. The elements that comprise this
header is 1#(token | quoted-string), where the definitions of value MUST be non-empty strings with characters in the range
/token/ and /quoted-string/ are as given in [RFC2616]. U+0021 to U+007E and MUST all be unique. The ABNF for the value
of this header is 1#(token | quoted-string), where the
definitions of 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 with the name "Sec-WebSocket-
Extensions". If present, this value indicates the protocol- Extensions". If present, this value indicates the protocol-
level extension(s) the client wishes to speak. The ABNF for the level extension(s) the client wishes to speak. The ABNF for the
value of this header is 1#(token | quoted-string), where the value of this header is 1#(token | quoted-string), where the
definitions of /token/ and /quoted-string/ are as given in definitions of constructs and rules are as given in [RFC2616].
[RFC2616]. The interpretation of this header is described in Section 8.1.
12. The request MAY include headers associated with sending cookies, 12. The request MAY include headers associated with sending cookies,
as defined by the appropriate specifications as defined by the appropriate specifications
[I-D.ietf-httpstate-cookie]. [I-D.ietf-httpstate-cookie].
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:
o If the status code received from the server is not 101, the client o If the status code received from the server is not 101, the client
skipping to change at page 29, line 4 skipping to change at page 28, line 12
the value "websocket", the client MUST fail the WebSocket the value "websocket", the client MUST fail the WebSocket
connection. connection.
o If the response lacks a Connection header or the Connection header o If the response lacks a Connection header or the Connection header
contains a value that is not an ASCII case-insensitive match for contains a value that is not an ASCII case-insensitive match for
the value "Upgrade", the client MUST fail the WebSocket the value "Upgrade", the client MUST fail the WebSocket
connection. connection.
o If the response lacks a Sec-WebSocket-Accept header or the Sec- o If the response lacks a Sec-WebSocket-Accept header or the Sec-
WebSocket-Accept contains a value other than the base64-encoded WebSocket-Accept contains a value other than the base64-encoded
SHA-1 of the concatenation of the Sec-WebSocket-Key with the SHA-1 of the concatenation of the Sec-WebSocket-Key (as a string,
string "258EAFA5-E914-47DA-95CA-C5AB0DC85B11", the client MUST not base64-decoded) with the string "258EAFA5-E914-47DA-95CA-
fail the WebSocket connection. C5AB0DC85B11", the client MUST fail the WebSocket connection.
Where the algorithm above requires that a user agent fail the Where the algorithm above requires that a user agent fail the
WebSocket connection, the user agent may first read an arbitrary WebSocket connection, the user agent may first read an arbitrary
number of further bytes from the connection (and then discard them) number of further bytes from the connection (and then discard them)
before actually *failing the WebSocket connection*. Similarly, if a before actually *failing the WebSocket connection*. Similarly, if a
user agent can show that the bytes read from the connection so far user agent can show that the bytes read from the connection so far
are such that there is no subsequent sequence of bytes that the are such that there is no subsequent sequence of bytes that the
server can send that would not result in the user agent being server can send that would not result in the user agent being
required to *fail the WebSocket connection*, the user agent may required to *fail the WebSocket connection*, the user agent may
immediately *fail the WebSocket connection* without waiting for those immediately *fail the WebSocket connection* without waiting for those
skipping to change at page 30, line 19 skipping to change at page 29, line 28
[RFC2616] that should be interpreted as a /resource name/ [RFC2616] that should be interpreted as a /resource name/
Section 3. Section 3.
2. A "Host" header containing the server's authority. 2. A "Host" header containing the server's authority.
3. A "Sec-WebSocket-Key" header with a base64-encoded value that, 3. A "Sec-WebSocket-Key" header with a base64-encoded value that,
when decoded, is 16 bytes in length. when decoded, is 16 bytes in length.
4. A "Sec-WebSocket-Origin" header. 4. A "Sec-WebSocket-Origin" header.
5. A "Sec-WebSocket-Version" header, with a value of 4. 5. A "Sec-WebSocket-Version" header, with a value of 5.
6. Optionally, a "Sec-WebSocket-Protocol header, with a list of 6. Optionally, a "Sec-WebSocket-Protocol header, with a list of
values indicating which protocols the client would like to speak, values indicating which protocols the client would like to speak,
ordered by preference. ordered by preference.
7. Optionally, a "Sec-WebSocket-Extensions" header, with a list of 7. Optionally, a "Sec-WebSocket-Extensions" header, with a list of
values indicating which extensions the client would like to values indicating which extensions the client would like to
speak. speak. The interpretation of this header is discussed in
Section 8.1.
8. Optionally, other headers, such as those used to send cookies to 8. Optionally, other headers, such as those used to send cookies to
a server. Unknown headers MUST be ignored. a server. Unknown headers 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.
skipping to change at page 31, line 44 skipping to change at page 31, line 9
subprotocols, then the value should be derived from the subprotocols, then the value should be derived from the
client's handshake, specifically by selecting one of the client's handshake, specifically by selecting one of the
values from the "Sec-WebSocket-Protocol" field. The absence values from the "Sec-WebSocket-Protocol" field. The absence
of such a field is equivalent to the null value. The empty of such a field is equivalent to the null value. The empty
string is not the same as the null value for these purposes. string is not the same as the null value for these purposes.
/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 should be derived from the multiple extensions, then the value should be derived from the
client's handshake, specifically by selecting one of the client's handshake, specifically by selecting one or more of
values from the "Sec-WebSocket-Extensions" field. The absence the values from the "Sec-WebSocket-Extensions" field. The
of such a field is equivalent to the null value. The empty absence of such a field is equivalent to the null value. The
string is not the same as the null value for these purposes. empty string is not the same as the null value for these
purposes. Extensions not listed by the client MUST NOT be
listed. The method by which these values should be selected
and interpreted is discussed in Section 8.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 101 response code. Such a response could look like 1. A 101 response code. Such a response could look like
"HTTP/1.1 101 Switching Protocols" "HTTP/1.1 101 Switching Protocols"
2. A "Sec-WebSocket-Accept" header. The value of this header is 2. A "Sec-WebSocket-Accept" header. The value of this header is
constructed by concatenating the value of the client's "Sec- constructed by concatenating /key/, defined above in
WebSocket-Key" header in the client's handshake with the Paragraph 2 of Section 5.2.2, with the string "258EAFA5-E914-
string "258EAFA5-E914-47DA-95CA-C5AB0DC85B11", taking the 47DA-95CA-C5AB0DC85B11", taking the SHA-1 hash of this
SHA-1 hash of this concatenated value to obtain a 20-byte concatenated value to obtain a 20-byte value, and base64-
value, and base64-encoding this 20-byte hash. encoding this 20-byte hash.
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 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
skipping to change at page 32, line 37 skipping to change at page 32, line 5
3. A "Sec-WebSocket-Nonce" header. The value of this header 3. A "Sec-WebSocket-Nonce" header. The value of this header
MUST be a nonce consisting of a randomly selected 16-byte MUST be a nonce consisting of a randomly selected 16-byte
value that has been base64-encoded [RFC3548]. The nonce MUST value that has been base64-encoded [RFC3548]. The nonce MUST
be randomly selected randomly for each connection. be randomly 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 sequence of bytes 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08
0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10, the value of the 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10, the value of the
header would be "AQIDBAUGBwgJCgsMDQ4PEC==" value header would be "AQIDBAUGBwgJCgsMDQ4PEC==" value
4. Optionally, a "Sec-WebSocket-Protocol" header, indicating the 4. Optionally, a "Sec-WebSocket-Protocol" header, with a value
subprotocol, if any, the server is prepared to speak. The /subprotocol/ as defined in Paragraph 2 of Section 5.2.2.
value of this header must be equal to one of the values
specified by the client in its opening handshake.
5. Optionally, a "Sec-WebSocket-Extensions" header, indicating 5. Optionally, a "Sec-WebSocket-Extensions" header, with a value
the protocol level extensions, if any, the server is prepared /extensions/ as defined in Paragraph 2 of Section 5.2.2.
to speak. The value of this header must be a subset of the
values specified by the client in its opening handshake.
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 connection, and if the client steps without aborting the WebSocket connection, and if the client
does not then fail the WebSocket connection, then the connection is does not then fail the WebSocket connection, then the connection is
established and the server may begin sending and receiving data, as established and the server may begin sending and receiving data, as
described in the next section. described in the next section.
6. Error Handling 6. Error Handling
6.1. Handling errors in UTF-8 from the server 6.1. Handling errors in UTF-8 from the server
skipping to change at page 34, line 7 skipping to change at page 34, line 7
When a server is to interpret a byte stream as UTF-8 but finds that When a server is to interpret a byte stream as UTF-8 but finds that
the byte stream is not in fact a valid UTF-8 stream, behavior is the byte stream is not in fact a valid UTF-8 stream, behavior is
undefined. A server could close the connection, convert invalid byte undefined. A server could close the connection, convert invalid byte
sequences to U+FFFD REPLACEMENT CHARACTERs, store the data verbatim, sequences to U+FFFD REPLACEMENT CHARACTERs, store the data verbatim,
or perform application-specific processing. Subprotocols layered on or perform application-specific processing. Subprotocols layered on
the WebSocket protocol might define specific behavior for servers. the WebSocket protocol might define specific behavior for servers.
7. Closing the connection 7. Closing the connection
7.1. Client-initiated closure 7.1. Abnormal closures
7.1.1. Client-initiated closure
Certain algorithms require the user agent to *fail the WebSocket Certain algorithms require the user agent to *fail the WebSocket
connection*. To do so, the user agent must close the WebSocket connection*. To do so, the user agent must close the WebSocket
connection, and may report the problem to the user (which would be connection, and may report the problem to the user (which would be
especially useful for developers). especially useful for developers).
Except as indicated above or as specified by the application layer Except as indicated above or as specified by the application layer
(e.g. a script using the WebSocket API), user agents should not close (e.g. a script using the WebSocket API), user agents should not close
the connection. the connection.
skipping to change at page 34, line 39 skipping to change at page 34, line 41
it was not a WebSocket server). it was not a WebSocket server).
o A WebSocket server that sent a correct opening handshake, but that o A WebSocket server that sent a correct opening handshake, but that
specified options that caused the client to drop the connection specified options that caused the client to drop the connection
(e.g. the server specified an origin that differed from the (e.g. the server specified an origin that differed from the
script's). script's).
o A WebSocket server that abruptly closed the connection after o A WebSocket server that abruptly closed the connection after
successfully completing the opening handshake. successfully completing the opening handshake.
7.2. Server-initiated closure 7.1.2. Server-initiated closure
Certain algorithms require or recommend that the server *abort the Certain algorithms require or recommend that the server *abort the
WebSocket connection* during the opening handshake. To do so, the WebSocket connection* during the opening handshake. To do so, the
server must simply close the WebSocket connection. server must simply close the WebSocket connection.
7.3. Closure 7.2. Normal closure of connections
To *close the WebSocket connection*, the user agent or server must To *close the WebSocket connection*, the user agent MUST first send a
close the TCP connection, using whatever mechanism possible (e.g. Close control frame, as described in Section 4.5.1. Upon receiving a
either the TCP RST or FIN mechanisms). When a user agent notices Close control frame, the other party sends a matching Close control
that the server has closed its connection, it must immediately close frame. Once an endpoint has sent or received an acknowledgement of a
its side of the connection also. Whether the user agent or the Close control frame, that endpoint must close the TCP connection,
server closes the connection first, it is said that the *WebSocket using whatever mechanism possible (e.g. either the TCP RST or FIN
connection is closed*. If the connection was closed after the client mechanisms). Whether the user agent or the server closes the
finished the WebSocket closing handshake, then the WebSocket connection first, it is said that the *WebSocket connection is
connection is said to have been closed _cleanly_. closed*. If the connection was closed after the client finished the
WebSocket closing handshake, then the WebSocket connection is said to
have been closed _cleanly_.
Servers may close the WebSocket connection whenever desired. User Servers may close the WebSocket connection whenever desired. User
agents should not close the WebSocket connection arbitrarily. agents should not close the WebSocket connection arbitrarily.
8. Known extensions 8. Extensions
WebSocket clients MAY request extensions to this specification, and
WebSocket servers MAY accept some or all extensions requested by the
client. A server MUST NOT respond with any extension not requested
by the client. If extension parameters are included in negotiations
between the client and the server, those parameters MUST be chosen in
accordance with the specification of the extension to which the
parameters apply.
8.1. Negotiating extensions
A client requests extensions by including a "Sec-WebSocket-
Extensions" header, which follows the normal rules for HTTP headers
(see [RFC2616] section 4.2) and the value of the header is defined by
the following ABNF:
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 | quoted-string ) ]
Note that like other HTTP headers, this header may be split or
combined across multiple lines. Ergo, the following are equivalent:
Sec-WebSocket-Extensions: foo
Sec-WebSocket-Extensions: bar; baz=2
is exactly equivalent to
Sec-WebSocket-Extensions: foo, bar; baz=2
Any extension-token used must either be a registered token
(registration TBD), or have a prefix of "x-" to indicate a private-
use token. The parameters supplied with any given extension MUST be
defined for that extension. Note that the client is only offering to
use any advertised extensions, and MUST NOT use them unless the
server accepts the extension.
Note that the order of extensions is significant. Any interactions
between multiple extensions MAY be defined in the documents defining
the extensions. In the absence of such definition, the
interpretation is that the headers listed by the client in its
request represent a preference of the headers it wishes to use, with
the first options listed being most preferable. The extensions
listed by the server in response represent the extensions actually in
use. Should the extensions modify the data and/or 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 server's response in
the opening handshake.
For example, if there are two extensions "foo" and "bar", if the
header |Sec-WebSocket-Extensions| sent by the server has the value
"foo, bar" then operations on the data will be made as
bar(foo(data)), be those changes to the data itself (such as
compression) or changes to the framing thay may "stack".
Non-normative examples of acceptable extension headers:
Sec-WebSocket-Extensions: deflate-stream
Sec-WebSocket-Extensions: mux; max-channels=4; flow-control, deflate-stream
Sec-WebSocket-Extensions: x-private-extension
A server accepts one or more extensions by including a |Sec-
WebSocket-Extensions| header containing one or more extensions which
were requested by the client. The interpretation of any extension
parameters, and what constitutes a valid response by a server to a
requested set of parameters by a client, will be defined by each such
extension.
8.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 section defines the meaning of
well-known extensions but implementations may use extensions defined well-known extensions but implementations may use extensions defined
separately as well. separately as well.
8.1. Compression 8.2.1. Compression
The registered extension token for this compression extension is The registered extension token for this compression extension is
"deflate-stream". "deflate-stream".
The extension does not have any per message extension data and it The extension does not have any per message extension data and it
does not define the use of any WebSocket reserved bits or op codes. does not define the use of any WebSocket reserved bits or op codes.
Senders using this extension MUST apply RFC 1951 encodings to all Senders using this extension MUST apply RFC 1951 encodings to all
bytes of the data stream following the handshake including both data bytes of the data stream following the handshake including both data
and control messages. The data stream MAY include multiple blocks of and control messages. The data stream MAY include multiple blocks of
skipping to change at page 41, line 43 skipping to change at page 43, line 43
None. None.
The |Sec-WebSocket-Key| and |Sec-WebSocket-Nonce| headers are used in The |Sec-WebSocket-Key| and |Sec-WebSocket-Nonce| headers are used in
the WebSocket handshake. They are sent from the client to the server the WebSocket handshake. They are sent from the client to the server
to provide part of the information used by the server to prove that to provide part of the information used by the server to prove that
it received a valid WebSocket handshake. This helps ensure that the it received a valid WebSocket handshake. This helps ensure that the
server does not accept connections from non-Web-Socket clients (e.g. server does not accept connections from non-Web-Socket clients (e.g.
HTTP clients) that are being abused to send data to unsuspecting HTTP clients) that are being abused to send data to unsuspecting
WebSocket servers. WebSocket servers.
10.5. Sec-WebSocket-Location 10.5. 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-Location Sec-WebSocket-Extensions
Applicable protocol Applicable protocol
http http
Status Status
reserved; do not use outside WebSocket handshake reserved; do not use outside WebSocket handshake
Author/Change controller Author/Change controller
IETF IETF
Specification document(s) Specification document(s)
This document is the relevant specification. This document is the relevant specification.
Related information Related information
None. None.
The |Sec-WebSocket-Location| header is used in the WebSocket The |Sec-WebSocket-Extensions| header is used in the WebSocket
handshake. It is sent from the server to the client to confirm the handshake. It is initially sent from the client to the server, and
URL of the connection. This enables the client to verify that the then subsequently sent from the servver to the client, to agree on a
connection was established to the right server, port, and path, set of protocol-level extensions to use during the connection.
instead of relying on the server to verify that the requested host,
port, and path are correct.
10.6. Sec-WebSocket-Origin 10.6. Sec-WebSocket-Accept
This section describes a header field for registration in the
Permanent Message Header Field Registry. [RFC3864]
Header field name
Sec-WebSocket-Accept
Applicable protocol
http
Status
reserved; do not use outside WebSocket handshake
Author/Change controller
IETF
Specification document(s)
This document is the relevant specification.
Related information
None.
The |Sec-WebSocket-Accept| header is used in the WebSocket handshake.
It is sent from the server to the client to confirm that the server
is willing to initiate the connection.
10.7. Sec-WebSocket-Origin
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-Origin
Applicable protocol Applicable protocol
http http
skipping to change at page 43, line 7 skipping to change at page 45, line 34
Related information Related information
None. None.
The |Sec-WebSocket-Origin| header is used in the WebSocket handshake. The |Sec-WebSocket-Origin| header is used in the WebSocket handshake.
It is sent from the server to the client to confirm the origin of the It is sent from the server to the client to confirm the origin of the
script that opened the connection. This enables user agents to script that opened the connection. This enables user agents to
verify that the server is willing to serve the script that opened the verify that the server is willing to serve the script that opened the
connection. connection.
10.7. Sec-WebSocket-Protocol 10.8. 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-Protocol Sec-WebSocket-Protocol
Applicable protocol Applicable protocol
http http
skipping to change at page 43, line 36 skipping to change at page 46, line 17
Related information Related information
None. None.
The |Sec-WebSocket-Protocol| header is used in the WebSocket The |Sec-WebSocket-Protocol| header is used in the WebSocket
handshake. It is sent from the client to the server and back from handshake. It is sent from the client to the server and back from
the server to the client to confirm the subprotocol of the the server to the client to confirm the subprotocol of the
connection. This enables scripts to both select a subprotocol and be connection. This enables scripts to both select a subprotocol and be
sure that the server agreed to serve that subprotocol. sure that the server agreed to serve that subprotocol.
10.8. Sec-WebSocket-Version 10.9. 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-Version Sec-WebSocket-Version
Applicable protocol Applicable protocol
http http
 End of changes. 62 change blocks. 
156 lines changed or deleted 271 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/