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/