draft-ietf-hybi-thewebsocketprotocol-05.txt   draft-ietf-hybi-thewebsocketprotocol-06.txt 
HyBi Working Group I. Fette HyBi Working Group I. Fette
Internet-Draft Google, Inc. Internet-Draft Google, Inc.
Intended status: Standards Track February 8, 2011 Intended status: Standards Track February 25, 2011
Expires: August 12, 2011 Expires: August 29, 2011
The WebSocket protocol The WebSocket protocol
draft-ietf-hybi-thewebsocketprotocol-05 draft-ietf-hybi-thewebsocketprotocol-06
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 August 12, 2011. This Internet-Draft will expire on August 29, 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 26 skipping to change at page 2, line 26
1.2. Protocol overview . . . . . . . . . . . . . . . . . . . . 4 1.2. Protocol overview . . . . . . . . . . . . . . . . . . . . 4
1.3. Opening handshake . . . . . . . . . . . . . . . . . . . . 6 1.3. Opening handshake . . . . . . . . . . . . . . . . . . . . 6
1.4. Closing handshake . . . . . . . . . . . . . . . . . . . . 8 1.4. Closing handshake . . . . . . . . . . . . . . . . . . . . 8
1.5. Design philosophy . . . . . . . . . . . . . . . . . . . . 9 1.5. Design philosophy . . . . . . . . . . . . . . . . . . . . 9
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 URIs . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1. Parsing WebSocket URLs . . . . . . . . . . . . . . . . . . 14 3.1. Parsing WebSocket URIs . . . . . . . . . . . . . . . . . . 14
3.2. Constructing WebSocket URLs . . . . . . . . . . . . . . . 15 3.2. Constructing WebSocket URIs . . . . . . . . . . . . . . . 15
3.3. Valid WebSocket URLs . . . . . . . . . . . . . . . . . . . 15 3.3. Valid WebSocket URIs . . . . . . . . . . . . . . . . . . . 15
4. Data Framing . . . . . . . . . . . . . . . . . . . . . . . . . 16 4. Data Framing . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2. Client-to-Server Masking . . . . . . . . . . . . . . . . . 16 4.2. Client-to-Server Masking . . . . . . . . . . . . . . . . . 16
4.3. Base Framing Protocol . . . . . . . . . . . . . . . . . . 17 4.3. Base Framing Protocol . . . . . . . . . . . . . . . . . . 17
4.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 19 4.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 19
4.5. Control Frames . . . . . . . . . . . . . . . . . . . . . . 20 4.5. Control Frames . . . . . . . . . . . . . . . . . . . . . . 21
4.5.1. Close . . . . . . . . . . . . . . . . . . . . . . . . 20 4.5.1. Close . . . . . . . . . . . . . . . . . . . . . . . . 21
4.5.2. Ping . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.5.2. Ping . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.5.3. Pong . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.5.3. Pong . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.6. Data Frames . . . . . . . . . . . . . . . . . . . . . . . 21 4.6. Data Frames . . . . . . . . . . . . . . . . . . . . . . . 22
4.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 22 4.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 23
5. Opening Handshake . . . . . . . . . . . . . . . . . . . . . . 24 5. Opening Handshake . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Client Requirements . . . . . . . . . . . . . . . . . . . 24 5.1. Client Requirements . . . . . . . . . . . . . . . . . . . 24
5.2. Server-side requirements . . . . . . . . . . . . . . . . . 28 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 . . . . . . . . 29 5.2.2. Sending the server's opening handshake . . . . . . . . 29
6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 33 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 32
6.1. Handling errors in UTF-8 from the server . . . . . . . . . 33 6.1. Handling errors in UTF-8 from the server . . . . . . . . . 32
6.2. Handling errors in UTF-8 from the client . . . . . . . . . 33 6.2. Handling errors in UTF-8 from the client . . . . . . . . . 32
7. Closing the connection . . . . . . . . . . . . . . . . . . . . 34 7. Closing the connection . . . . . . . . . . . . . . . . . . . . 33
7.1. Abnormal closures . . . . . . . . . . . . . . . . . . . . 34 7.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 33
7.1.1. Client-initiated closure . . . . . . . . . . . . . . . 34 7.1.1. Close the WebSocket Connection . . . . . . . . . . . . 33
7.1.2. Server-initiated closure . . . . . . . . . . . . . . . 34 7.1.2. Start the WebSocket Closing Handshake . . . . . . . . 33
7.2. Normal closure of connections . . . . . . . . . . . . . . 34 7.1.3. The WebSocket Connection Is Closed . . . . . . . . . . 33
8. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 36 7.1.4. Fail the WebSocket Connection . . . . . . . . . . . . 33
8.1. Negotiating extensions . . . . . . . . . . . . . . . . . . 36 7.2. Abnormal closures . . . . . . . . . . . . . . . . . . . . 34
8.2. Known extensions . . . . . . . . . . . . . . . . . . . . . 37 7.2.1. Client-initiated closure . . . . . . . . . . . . . . . 34
8.2.1. Compression . . . . . . . . . . . . . . . . . . . . . 37 7.2.2. Server-initiated closure . . . . . . . . . . . . . . . 34
9. Security considerations . . . . . . . . . . . . . . . . . . . 39 7.3. Normal closure of connections . . . . . . . . . . . . . . 34
10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 40 7.4. Status codes . . . . . . . . . . . . . . . . . . . . . . . 34
10.1. Registration of ws: scheme . . . . . . . . . . . . . . . . 40 7.4.1. Defined Status Codes . . . . . . . . . . . . . . . . . 34
10.2. Registration of wss: scheme . . . . . . . . . . . . . . . 41 7.4.2. Reserved status code ranges . . . . . . . . . . . . . 35
10.3. Registration of the "WebSocket" HTTP Upgrade keyword . . . 42 8. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 37
10.4. Sec-WebSocket-Key and Sec-WebSocket-Nonce . . . . . . . . 42 8.1. Negotiating extensions . . . . . . . . . . . . . . . . . . 37
10.5. Sec-WebSocket-Extensions . . . . . . . . . . . . . . . . . 43 8.2. Known extensions . . . . . . . . . . . . . . . . . . . . . 38
10.6. Sec-WebSocket-Accept . . . . . . . . . . . . . . . . . . . 44 8.2.1. Compression . . . . . . . . . . . . . . . . . . . . . 38
10.7. Sec-WebSocket-Origin . . . . . . . . . . . . . . . . . . . 45 9. Security considerations . . . . . . . . . . . . . . . . . . . 40
10.8. Sec-WebSocket-Protocol . . . . . . . . . . . . . . . . . . 45 10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 42
10.9. Sec-WebSocket-Version . . . . . . . . . . . . . . . . . . 46 10.1. Registration of ws: scheme . . . . . . . . . . . . . . . . 42
11. Using the WebSocket protocol from other specifications . . . . 47 10.2. Registration of wss: scheme . . . . . . . . . . . . . . . 43
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 48 10.3. Registration of the "WebSocket" HTTP Upgrade keyword . . . 44
13. Normative References . . . . . . . . . . . . . . . . . . . . . 49 10.4. Sec-WebSocket-Key . . . . . . . . . . . . . . . . . . . . 44
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 51 10.5. Sec-WebSocket-Extensions . . . . . . . . . . . . . . . . . 45
10.6. Sec-WebSocket-Accept . . . . . . . . . . . . . . . . . . . 46
10.7. Sec-WebSocket-Origin . . . . . . . . . . . . . . . . . . . 46
10.8. Sec-WebSocket-Protocol . . . . . . . . . . . . . . . . . . 47
10.9. Sec-WebSocket-Version . . . . . . . . . . . . . . . . . . 47
11. Using the WebSocket protocol from other specifications . . . . 49
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50
13. Appendix: List of Changes . . . . . . . . . . . . . . . . . . 51
13.1. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 51
14. Normative References . . . . . . . . . . . . . . . . . . . . . 53
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 55
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: 5 Sec-WebSocket-Version: 6
The handshake from the server looks as follows: The handshake from the server looks as follows:
HTTP/1.1 101 Switching Protocols HTTP/1.1 101 Switching Protocols
Upgrade: websocket Upgrade: websocket
Connection: Upgrade Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-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
cookies required to identify the user. The format and parsing of cookies required to identify the user. The format and parsing of
skipping to change at page 6, line 25 skipping to change at page 6, line 24
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: 5 Sec-WebSocket-Version: 6
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 50 skipping to change at page 7, line 49
then base64-encoded, to give the value "s3pPLMBiTxaQ9kYGzzhZRbK+ then base64-encoded, to give the value "s3pPLMBiTxaQ9kYGzzhZRbK+
xOo=". This value would then be echoed in the header |Sec-WebSocket- xOo=". This value would then be echoed in the header |Sec-WebSocket-
Accept|. 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 if
websocket connection aborted. The headers follow the status code. semantics of that status code are not defined in the context of a
WebSocket connection, and the 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
skipping to change at page 8, line 44 skipping to change at page 8, line 45
The server can also set cookie-related option fields to _set_ The server can also set cookie-related option fields to _set_
cookies, as in HTTP. cookies, as in HTTP.
1.4. Closing handshake 1.4. Closing handshake
_This section is non-normative._ _This section is non-normative._
The closing handshake is far simpler than the opening handshake. The closing handshake is far simpler than the opening handshake.
Either peer can send a control frame with data containing a specified Either peer can send a control frame with data containing a specified
control sequence to begin the closing handshake. Upon receiving such control sequence to begin the closing handshake (detailed in
a frame, the other peer sends an identical frame in acknowledgement, Section 4.5.1). Upon receiving such a frame, the other peer sends a
if it hasn't already sent one. Upon receiving _that_ control frame, close frame in response, if it hasn't already sent one. Upon
the first peer then closes the connection, safe in the knowledge that receiving _that_ control frame, the first peer then closes the
no further data is forthcoming. connection, safe in the knowledge that no further data is
forthcoming.
After sending a control frame indicating the connection should be After sending a control frame indicating the connection should be
closed, a peer does not send any further data; after receiving a closed, a peer does not send any further data; after receiving a
control frame indicating the connection should be closed, a peer control frame indicating the connection should be closed, a peer
discards any further data received. discards any further data received.
It is safe for both peers to initiate this handshake simultaneously. It is safe for both peers to initiate this handshake simultaneously.
The closing handshake is intended to replace the TCP closing The closing handshake is intended to replace the TCP closing
handshake (FIN/ACK), on the basis that the TCP closing handshake is handshake (FIN/ACK), on the basis that the TCP closing handshake is
not always reliable end-to-end, especially in the presence of man-in- not always reliable end-to-end, especially in the presence of man-in-
the-middle proxies and other intermediaries. the-middle proxies and other intermediaries.
By sending a close frame and waiting for a close frame in response,
1.5. Design philosophy 1.5. Design philosophy
_This section is non-normative._ _This section is non-normative._
The WebSocket protocol is designed on the principle that there should The WebSocket protocol is designed on the principle that there should
be minimal framing (the only framing that exists is to make the be minimal framing (the only framing that exists is to make the
protocol frame-based instead of stream-based, and to support a protocol frame-based instead of stream-based, and to support a
distinction between Unicode text and binary frames). It is expected distinction between Unicode text and binary frames). It is expected
that metadata would be layered on top of WebSocket by the application that metadata would be layered on top of WebSocket by the application
layer, in the same way that metadata is layered on top of TCP by the layer, in the same way that metadata is layered on top of TCP by the
skipping to change at page 9, line 41 skipping to change at page 9, line 45
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 additional concepts such as multiplexing and likely introduce additional concepts such as multiplexing.
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 10, line 21 skipping to change at page 10, line 23
limiting the data that can be inserted into the connection before the limiting the data that can be inserted into the connection before the
handshake is finished (thus limiting how much the server can be handshake is finished (thus limiting how much the server can be
influenced). influenced).
It is similarly intended to fail to establish a connection when data It is similarly intended to fail to establish a connection when data
from other protocols, especially HTTP, is sent to a WebSocket server, from other protocols, especially HTTP, is sent to a WebSocket server,
for example as might happen if an HTML |form| were submitted to a for example as might happen if an HTML |form| were submitted to a
WebSocket server. This is primarily achieved by requiring that the WebSocket server. This is primarily achieved by requiring that the
server prove that it read the handshake, which it can only do if the server prove that it read the handshake, which it can only do if the
handshake contains the appropriate parts which themselves can only be handshake contains the appropriate parts which themselves can only be
sent by a WebSocket handshake; in particular, fields starting with sent by a WebSocket handshake. In particular, at the time of writing
|Sec-| cannot be set by an attacker from a Web browser, even when of this specification, fields starting with |Sec-| cannot be set by
using |XMLHttpRequest|. an attacker from a Web browser using only HTML and JavaScript APIs
such as |XMLHttpRequest|.
1.7. Relationship to TCP and HTTP 1.7. Relationship to TCP and HTTP
_This section is non-normative._ _This section is non-normative._
The WebSocket protocol is an independent TCP-based protocol. Its The WebSocket protocol is an independent TCP-based protocol. Its
only relationship to HTTP is that its handshake is interpreted by only relationship to HTTP is that its handshake is interpreted by
HTTP servers as an Upgrade request. HTTP servers as an Upgrade request.
Based on the expert recommendation of the IANA, the WebSocket Based on the expert recommendation of the IANA, the WebSocket
protocol by default uses port 80 for regular WebSocket connections protocol by default uses port 80 for regular WebSocket connections
and port 443 for WebSocket connections tunneled over TLS. and port 443 for WebSocket connections tunneled over TLS.
1.8. Establishing a connection 1.8. Establishing a connection
_This section is non-normative._ _This section is non-normative._
There are several options for establishing a WebSocket connection.
On the face of it, the simplest method would seem to be to use port
80 to get a direct connection to a WebSocket server. Port 80
traffic, however, will often be intercepted by HTTP proxies, which
can lead to the connection failing to be established.
The most reliable method, therefore, is to use TLS encryption and
port 443 to connect directly to a WebSocket server. This has the
advantage of being more secure; however, TLS encryption can be
computationally expensive.
When a connection is to be made to a port that is shared by an HTTP When a connection is to be made to a port that is shared by an HTTP
server (a situation that is quite likely to occur with traffic to server (a situation that is quite likely to occur with traffic to
ports 80 and 443), the connection will appear to the HTTP server to ports 80 and 443), the connection will appear to the HTTP server to
be a regular GET request with an Upgrade offer. In relatively simple be a regular GET request with an Upgrade offer. In relatively simple
setups with just one IP address and a single server for all traffic setups with just one IP address and a single server for all traffic
to a single hostname, this might allow a practical way for systems to a single hostname, this might allow a practical way for systems
based on the WebSocket protocol to be deployed. In more elaborate based on the WebSocket protocol to be deployed. In more elaborate
setups (e.g. with load balancers and multiple servers), a dedicated setups (e.g. with load balancers and multiple servers), a dedicated
set of hosts for WebSocket connections separate from the HTTP servers set of hosts for WebSocket connections separate from the HTTP servers
is probably easier to manage. is probably easier to manage. At the time of writing of this
specification, it should be noted that connections on port 80 and 443
have significantly different success rates, with connections on port
443 being significantly more likely to succeed, though this may
change with time.
1.9. Subprotocols using the WebSocket protocol 1.9. Subprotocols using the WebSocket protocol
_This section is non-normative._ _This section is non-normative._
The client can request that the server use a specific subprotocol by The client can request that the server use a specific subprotocol by
including the |Sec-Websocket-Protocol| field in its handshake. If it including the |Sec-WebSocket-Protocol| field in its handshake. If it
is specified, the server needs to include the same field and one of is specified, the server needs to include the same field and one of
the selected subprotocol values in its response for the connection to the selected subprotocol values in its response for the connection to
be established. be established.
These subprotocol names do not need to be registered, but if a These subprotocol names do not need to be registered, but if a
subprotocol is intended to be implemented by multiple independent subprotocol is intended to be implemented by multiple independent
WebSocket servers, potential clashes with the names of subprotocols WebSocket servers, potential clashes with the names of subprotocols
defined independently can be avoided by using names that contain the defined independently can be avoided by using names that contain the
domain name of the subprotocol's originator. For example, if Example domain name of the subprotocol's originator. For example, if Example
Corporation were to create a Chat subprotocol to be implemented by Corporation were to create a Chat subprotocol to be implemented by
skipping to change at page 13, line 5 skipping to change at page 13, line 5
range U+0061 to U+007A (i.e. LATIN SMALL LETTER A to LATIN SMALL range U+0061 to U+007A (i.e. LATIN SMALL LETTER A to LATIN SMALL
LETTER Z). LETTER Z).
Comparing two strings in an *ASCII case-insensitive* manner means Comparing two strings in an *ASCII case-insensitive* manner means
comparing them exactly, code point for code point, except that the comparing them exactly, code point for code point, except that the
characters in the range U+0041 to U+005A (i.e. LATIN CAPITAL LETTER characters in the range U+0041 to U+005A (i.e. LATIN CAPITAL LETTER
A to LATIN CAPITAL LETTER Z) and the corresponding characters in the A to LATIN CAPITAL LETTER Z) and the corresponding characters in the
range U+0061 to U+007A (i.e. LATIN SMALL LETTER A to LATIN SMALL range U+0061 to U+007A (i.e. LATIN SMALL LETTER A to LATIN SMALL
LETTER Z) are considered to also match. LETTER Z) are considered to also match.
The term "URL" is used in this section in a manner consistent with The term "URI" is used in this section in a manner consistent with
the terminology used in HTML, namely, to denote a string that might the terminology used in HTML, namely, to denote a string that might
or might not be a valid URI or IRI and to which certain error or might not be a valid URI or IRI and to which certain error
handling behaviors will be applied when the string is parsed. [HTML] handling behaviors will be applied when the string is parsed.
[RFC3986]
When an implementation is required to _send_ data as part of the When an implementation is required to _send_ data as part of the
WebSocket protocol, the implementation may delay the actual WebSocket protocol, the implementation may delay the actual
transmission arbitrarily, e.g. buffering data so as to send fewer IP transmission arbitrarily, e.g. buffering data so as to send fewer IP
packets. packets.
3. WebSocket URLs 3. WebSocket URIs
3.1. Parsing WebSocket URLs 3.1. Parsing WebSocket URIs
The steps to *parse a WebSocket URL's components* from a string /url/ The steps to *parse a WebSocket URI's components* from a string /uri/
are as follows. These steps return either a /host/, a /port/, a are as follows. These steps return either a /host/, a /port/, a
/resource name/, and a /secure/ flag, or they fail. /resource name/, and a /secure/ flag, or they fail.
1. If the /url/ string is not an absolute URL, then fail this 1. If the /uri/ string is not an absolute URI, then fail this
algorithm. [RFC3986] [RFC3987] algorithm. [RFC3986] [RFC3987]
2. Resolve the /url/ string using the resolve a Web address 2. Resolve the /uri/ string using the resolve a Web address
algorithm defined by the Web addresses specification, with the algorithm defined by the Web addresses specification, with the
URL character encoding set to UTF-8. [RFC3629] [RFC3986] URI character encoding set to UTF-8. [RFC3629] [RFC3986]
[RFC3987] [RFC3987]
NOTE: It doesn't matter what it is resolved relative to, since NOTE: It doesn't matter what it is resolved relative to, since
we already know it is an absolute URL at this point. we already know it is an absolute URI at this point.
3. If /url/ does not have a <scheme> component whose value, when 3. If /uri/ does not have a <scheme> component whose value, when
converted to ASCII lowercase, is either "ws" or "wss", then fail converted to ASCII lowercase, is either "ws" or "wss", then fail
this algorithm. this algorithm.
4. If /url/ has a <fragment> component, then fail this algorithm. 4. If /uri/ has a <fragment> component, then fail this algorithm.
5. If the <scheme> component of /url/ is "ws", set /secure/ to 5. If the <scheme> component of /uri/ is "ws", set /secure/ to
false; otherwise, the <scheme> component is "wss", set /secure/ false; otherwise, if the <scheme> component is "wss", set
to true. /secure/ to true; otherwise, fail this algorithm.
6. Let /host/ be the value of the <host> component of /url/, 6. Let /host/ be the value of the <host> component of /uri/,
converted to ASCII lowercase. converted to ASCII lowercase.
7. If /url/ has a <port> component, then let /port/ be that 7. If /uri/ has a <port> component, then let /port/ be that
component's value; otherwise, there is no explicit /port/. component's value; otherwise, there is no explicit /port/.
8. If there is no explicit /port/, then: if /secure/ is false, let 8. If there is no explicit /port/, then: if /secure/ is false, let
/port/ be 80, otherwise let /port/ be 443. /port/ be 80, otherwise let /port/ be 443.
9. Let /resource name/ be the value of the <path> component (which 9. Let /resource name/ be the value of the <path> component (which
might be empty) of /url/. might be empty) of /uri/.
10. If /resource name/ is the empty string, set it to a single 10. If /resource name/ is the empty string, set it to a single
character U+002F SOLIDUS (/). character U+002F SOLIDUS (/).
11. If /url/ has a <query> component, then append a single U+003F 11. If /uri/ has a <query> component, then append a single U+003F
QUESTION MARK character (?) to /resource name/, followed by the QUESTION MARK character (?) to /resource name/, followed by the
value of the <query> component. value of the <query> component.
12. Return /host/, /port/, /resource name/, and /secure/. 12. Return /host/, /port/, /resource name/, and /secure/.
3.2. Constructing WebSocket URLs 3.2. Constructing WebSocket URIs
The steps to *construct a WebSocket URL* from a /host/, a /port/, a The steps to *construct a WebSocket URI* from a /host/, a /port/, a
/resource name/, and a /secure/ flag, are as follows: /resource name/, and a /secure/ flag, are as follows:
1. Let /url/ be the empty string. 1. Let /uri/ be the empty string.
2. If the /secure/ flag is false, then append the string "ws://" to 2. If the /secure/ flag is false, then append the string "ws://" to
/url/. Otherwise, append the string "wss://" to /url/. /uri/. Otherwise, append the string "wss://" to /uri/.
3. Append /host/ to /url/. 3. Append /host/ to /uri/.
4. If the /secure/ flag is false and port is not 80, or if the 4. If the /secure/ flag is false and port is not 80, or if the
/secure/ flag is true and port is not 443, then append the string /secure/ flag is true and port is not 443, then append the string
":" followed by /port/ to /url/. ":" followed by /port/ to /uri/.
5. Append /resource name/ to /url/. 5. Append /resource name/ to /uri/.
6. Return /url/. 6. Return /uri/.
3.3. Valid WebSocket URLs 3.3. Valid WebSocket URIs
For a WebSocket URL to be considered valid, the following conditions For a WebSocket URI 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 /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 (/).
Any WebSocket URLs not meeting the above criteria are considered Any WebSocket URIs 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 URI. A client SHOULD attempt to parse a URI
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 URI, but MUST NOT attempt to connect with such an unparsed URI, 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
4.1. Overview 4.1. Overview
In the WebSocket protocol, data is transmitted using a sequence of In the WebSocket protocol, data is transmitted using a sequence of
frames. Frames sent from the client to the server are masked to frames. Frames sent from the client to the server are masked to
avoid confusing network intermediaries, such as intercepting proxies. avoid confusing network intermediaries, such as intercepting proxies.
skipping to change at page 16, line 23 skipping to change at page 16, line 23
The base framing protocol defines a frame type with an opcode, a The base framing protocol defines a frame type with an opcode, a
payload length, and designated locations for extension and payload length, and designated locations for extension and
application data, which together define the _payload_ data. Certain application data, which together define the _payload_ data. Certain
bits and opcodes are reserved for future expansion of the protocol. bits and opcodes are reserved for future expansion of the protocol.
As such, In the absence of extensions negotiated during the opening As such, In the absence of extensions negotiated during the opening
handshake (Section 5), all reserved bits MUST be 0 and reserved handshake (Section 5), all reserved bits MUST be 0 and reserved
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 endpoint has sent
generated a close message (Section 4.5.1). 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 contained completely within the frame. The masking-key is contained completely within the frame.
The masking-key is a 32-bit value chosen at random by the client. The masking-key is a 32-bit value chosen at random by the client.
The masking-key MUST be derived from a strong source of entropy, and The masking-key MUST be derived from a strong source of entropy, and
the masking-key for a given frame MUST NOT make it simple for a the masking-key for a given frame MUST NOT make it simple for a
server to predict the masking-key for a subsequent frame. server to predict the masking-key for a subsequent frame.
Each masked frame consists of a 32-bit masking-key followed by Each masked frame consists of a 32-bit masking-key followed by
masked-data: masked-data:
masked-frame = masking-key masked-data masked-frame = masking-key masked-data
masking-key = 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.
Octet i of the masked-data is the XOR of octet i of the clear text Octet i of the masked-data is the XOR of octet i of the clear text
frame with octet i modulo 4 of the masking-key: frame with octet i modulo 4 of the masking-key:
j = i MOD 4 j = i MOD 4
skipping to change at page 19, line 48 skipping to change at page 19, line 48
frame-length-16 = %x0000-FFFF frame-length-16 = %x0000-FFFF
frame-length-63 = %x0000000000000000-7FFFFFFFFFFFFFFF frame-length-63 = %x0000000000000000-7FFFFFFFFFFFFFFF
frame-extension = *( %x00-FF ) ; to be defined later frame-extension = *( %x00-FF ) ; to be defined later
application-data = *( %x00-FF ) application-data = *( %x00-FF )
4.4. Fragmentation 4.4. Fragmentation
The primary purpose of fragmentation is to allow sending a message
that is of unknown size when the message is started without having to
buffer that message. If messages couldn't be fragmented, then an
endpoint would have to buffer the entire message so its length could
be counted before first byte is sent. With fragmentation, a server
or intermediary may choose a reasonable size buffer, and when the
buffer is full write a fragment to the network.
A secondary use-case for fragmentation is for multiplexing, where it
is not desirable for a large message on one logical channel to
monopolize the output channel, so the MUX needs to be free to split
the message into smaller fragments to better share the output
channel.
The following rules apply to fragmentation: The following rules apply to fragmentation:
o An unfragmented message consists of a single frame with the FIN o An unfragmented message consists of a single frame with the FIN
bit set and an opcode other than 0. bit set and an opcode other than 0.
o A fragmented message consists of a single frame with the FIN bit o A fragmented message consists of a single frame with the FIN bit
clear and an opcode other than 0, followed by zero or more frames clear and an opcode other than 0, followed by zero or more frames
with the FIN bit clear and the opcode set to 0, and terminated by with the FIN bit clear and the opcode set to 0, and terminated by
a single frame with the FIN bit set and an opcode of 0. Its a single frame with the FIN bit set and an opcode of 0. Its
content is the concatenation of the application data from each of content is the concatenation of the application data from each of
those frames in order. those frames in order. As an example, for a text message sent as
three fragments, the first fragment would have an opcode of 0x4
and a FIN bit clear, the second fragment would have an opcode of
0x0 and a FIN bit clear, and the third fragment would have an
opcode of 0x0 and a FIN bit that is set.
o _Note: There is an open question as to whether control frames be o Control frames MAY be injected in the middle of a fragmented
interjected in the middle of a fragmented message. If so, it must message. Control frames themselves MUST NOT be fragmented. _Note:
be decided whether they be fragmented (which would require keeping if control frames could not be interjected, the latency of a ping,
a stack of "in-progress" messages)._ for example, would be very long if behind a large message. As
such, an endpoint MUST be capable of handling control frames in
the middle of a fragmented message._
o A sender MAY create fragments of any size for non control o A sender MAY create fragments of any size for non control
messages. messages.
o Clients and servers MUST support receiving both fragmented and o Clients and servers MUST support receiving both fragmented and
unfragmented messages. unfragmented messages.
o An intermediary MAY change the fragmentation of a message if the o An intermediary MAY change the fragmentation of a message if the
message uses only opcode and reserved bit values known to the message uses only opcode and reserved bit values known to the
intermediary. intermediary.
o As a consequence of these rules, all fragments of a message are of
the same type, as set by the first fragment's opcode. Since
Control frames cannot be fragmented, the type for all fragments in
a message MUST be either text or binary, or one of the reserved
opcodes.
4.5. Control Frames 4.5. Control Frames
Control frames have opcodes of 0x01 (Close), 0x02 (Ping), or 0x03 Control frames have opcodes of 0x01 (Close), 0x02 (Ping), or 0x03
(Pong). Control frames are used to communicate state about the (Pong). Control frames are used to communicate state about the
websocket. websocket. Control frames can be interjected in the middle of a
fragmented message.
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 The Close message MAY contain a body (the "application data" portion
length. If the close is initiated by the client, the first byte of of the frame) that indicates a reason for closing, such as an
the body MUST be a 0x43. If the close is initiated by the server, endpoint shutting down, an endpoint having received a message too
the first byte of the body MUST be a 0x53. The body MAY contain large, or an endpoint having received a message that does not conform
additional bytes, the meaning of those bytes are not defined by this to the format expected by the other endpoint. If there is a body,
version of the protocol. the first two bytes of the body MUST be a 2-byte integer (in network
byte order) representing a status code defined in Section 7.4.
Following the 2-byte integer the body MAY contain UTF-8 encoded data,
the interpretation of which is not defined by this specification.
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 If an endpoint receives a Close message and that endpoint did not
message body matches the body of a close message previously sent by previously send a Close message, the endpoint MUST send a Close
the receiver. message in response. It SHOULD do so as soon as is practical.
Upon receipt of an initiated close the endpoint MUST send a close
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 After both sending and receiving a close message, an endpoint
received a close acknowledgment or sent a close acknowledgment. considers the websocket connection closed, and SHOULD close the
underlying TCP connection.
To prevent a situation where ambiguity arises from a client and If a client and server both send a Close message at the same time,
server both sending a close frame at approximately the same time, the both endpoints will have sent and received a Close message and should
close frame has a body that can be used to distinguish whether a consider the websocket connection closed and close the underlying TCP
close frame is an initiation of a close event or the acknowledgement connection.
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
skipping to change at page 24, line 16 skipping to change at page 24, line 16
5.1. Client Requirements 5.1. Client Requirements
User agents running in controlled environments, e.g. browsers on User agents running in controlled environments, e.g. browsers on
mobile handsets tied to specific carriers, may offload the management mobile handsets tied to specific carriers, may offload the management
of the connection to another agent on the network. In such a of the connection to another agent on the network. In such a
situation, the user agent for the purposes of conformance is situation, the user agent for the purposes of conformance is
considered to include both the handset software and any such agents. considered to include both the handset software and any such agents.
When the user agent is to *establish a WebSocket connection* to a When the user agent is to *establish a WebSocket connection* to a
WebSocket URL /url/, it must meet the following requirements. In the WebSocket URI /uri/, it must meet the following requirements. In the
following text, we will use terms from Section 3 such as "/host/" and following text, we will use terms from Section 3 such as "/host/" and
"/secure/ flag" as defined in that section. "/secure/ flag" as defined in that section.
1. The WebSocket URL and its components MUST be valid according to 1. The WebSocket URI and its components MUST be valid according to
Section 3.3. If any of the requirements are not met, the client Section 3.3. If any of the requirements are not met, the client
MUST fail the WebSocket connection and abort these steps. MUST fail the WebSocket connection and abort these steps.
2. If the user agent already has a WebSocket connection to the 2. If the user agent already has a WebSocket connection to the
remote host (IP address) identified by /host/, even if known by remote host (IP address) identified by /host/, even if known by
another name, the user agent MUST wait until that connection has another name, the user agent MUST wait until that connection has
been established or for that connection to have failed. If been established or for that connection to have failed. There
MUST be no more than one connection in a CONNECTING state. If
multiple connections to the same IP address are attempted multiple connections to the same IP address are attempted
simultaneously, the user agent MUST serialize them so that there simultaneously, the user agent MUST serialize them so that there
is no more than one connection at a time running through the is no more than one connection at a time running through the
following steps. following steps.
If the user agent cannot determine the IP address of the remote If the user agent cannot determine the IP address of the remote
host (for example because all communication is being done through host (for example because all communication is being done through
a proxy server that performs DNS queries itself), then the user a proxy server that performs DNS queries itself), then the user
agent MUST assume for the purposes of this step that each host agent MUST assume for the purposes of this step that each host
name refers to a distinct remote host, but should instead limit name refers to a distinct remote host, but should instead limit
skipping to change at page 25, line 37 skipping to change at page 25, line 38
TCP connection SHOULD be opened to the host given by /host/ and TCP connection SHOULD be opened to the host given by /host/ and
the port given by /port/. the port given by /port/.
NOTE: Implementations that do not expose explicit UI for NOTE: Implementations that do not expose explicit UI for
selecting a proxy for WebSocket connections separate from other selecting a proxy for WebSocket connections separate from other
proxies are encouraged to use a SOCKS proxy for WebSocket proxies are encouraged to use a SOCKS proxy for WebSocket
connections, if available, or failing that, to prefer the proxy connections, if available, or failing that, to prefer the proxy
configured for HTTPS connections over the proxy configured for configured for HTTPS connections over the proxy configured for
HTTP connections. HTTP connections.
For the purpose of proxy autoconfiguration scripts, the URL to For the purpose of proxy autoconfiguration scripts, the URI to
pass the function must be constructed from /host/, /port/, pass the function must be constructed from /host/, /port/,
/resource name/, and the /secure/ flag using the steps to /resource name/, and the /secure/ flag using the steps to
construct a WebSocket URL. construct a WebSocket URI.
NOTE: The WebSocket protocol can be identified in proxy NOTE: The WebSocket protocol can be identified in proxy
autoconfiguration scripts from the scheme ("ws:" for unencrypted autoconfiguration scripts from the scheme ("ws:" for unencrypted
connections and "wss:" for encrypted connections). connections and "wss:" for encrypted connections).
4. If the connection could not be opened, either because a direct 4. If the connection could not be opened, either because a direct
connection failed or because any proxy used returned an error, connection failed or because any proxy used returned an error,
then the user agent MUST fail the WebSocket connection and abort then the user agent MUST fail the WebSocket connection and abort
the connection attempt. the connection attempt.
skipping to change at page 26, line 27 skipping to change at page 26, line 28
MUST send a handshake to the server. The handshake consists of an MUST send a handshake to the server. The handshake consists of an
HTTP upgrade request, along with a list of required and optional HTTP upgrade request, along with a list of required and optional
headers. The requirements for this handshake are as follows. headers. The requirements for this handshake are as follows.
1. The handshake must be a valid HTTP request as specified by 1. The handshake must be a valid HTTP request as specified by
[RFC2616]. [RFC2616].
2. The Method of the request MUST be GET and the HTTP version MUST 2. The Method of the request MUST be GET and the HTTP version MUST
be at least 1.1. be at least 1.1.
For example, if the WebSocket URL is "ws://example.com/chat", For example, if the WebSocket URI is "ws://example.com/chat",
The first line sent SHOULD be "GET /chat HTTP/1.1" The first line sent SHOULD be "GET /chat HTTP/1.1"
3. The request must contain a "Request-URI" as part of the GET 3. The request must contain a "Request-URI" as part of the GET
method. This MUST match the /resource name/ Section 3. method. This MUST match the /resource name/ Section 3.
4. The request MUST contain a "Host" header whose value is equal to 4. The request MUST contain a "Host" header whose value is equal to
the authority component of the WebSocket URL. the authority component of the WebSocket URI.
5. The request MUST contain an "Upgrade" header whose value is 5. The request MUST contain an "Upgrade" header whose value is
equal to "websocket". equal to "websocket".
6. The request MUST contain a "Connection" header whose value is 6. The request MUST contain a "Connection" header whose value MUST
equal to "Upgrade". include the "Upgrade" token.
7. The request MUST include a header with the name "Sec-WebSocket- 7. The request MUST include a header with the name "Sec-WebSocket-
Key". The value of this header MUST be a nonce consisting of a Key". The value of this header MUST be a nonce consisting of a
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
skipping to change at page 27, line 21 skipping to change at page 27, line 22
which the code establishing the connection is running, and MUST which the code establishing the connection is running, and MUST
be lower-case. The value MUST NOT contain letters in the range 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 U+0041 to U+005A (i.e. LATIN CAPITAL LETTER A to LATIN CAPITAL
LETTER Z) [I-D.ietf-websec-origin]. 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 5. Version". The value of this header must be 6.
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 elements that comprise this the client wishes to speak. The elements that comprise this
value MUST be non-empty strings with characters in the range value MUST be non-empty strings with characters in the range
U+0021 to U+007E and MUST all be unique. The ABNF for the value 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 of this header is 1#(token | quoted-string), where the
definitions of constructs and rules are as given in [RFC2616]. 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
value of this header is 1#(token | quoted-string), where the interpretation and format of this header is described in
definitions of constructs and rules are as given in [RFC2616]. Section 8.1.
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 28, line 47 skipping to change at page 28, line 48
_This section only applies to servers._ _This section only applies to servers._
Servers may offload the management of the connection to other agents Servers may offload the management of the connection to other agents
on the network, for example load balancers and reverse proxies. In on the network, for example load balancers and reverse proxies. In
such a situation, the server for the purposes of conformance is such a situation, the server for the purposes of conformance is
considered to include all parts of the server-side infrastructure considered to include all parts of the server-side infrastructure
from the first device to terminate the TCP connection all the way to from the first device to terminate the TCP connection all the way to
the server that processes requests and sends responses. the server that processes requests and sends responses.
EXAMPLE: For example, a data center might have a server that responds EXAMPLE: For example, a data center might have a server that responds
to Web Socket requests with an appropriate handshake, and then passes to WebSocket requests with an appropriate handshake, and then passes
the connection to another server to actually process the data frames. the connection to another server to actually process the data frames.
For the purposes of this specification, the "server" is the For the purposes of this specification, the "server" is the
combination of both computers. combination of both computers.
5.2.1. Reading the client's opening handshake 5.2.1. Reading the client's opening handshake
When a client starts a WebSocket connection, it sends its part of the When a client starts a WebSocket connection, it sends its part of the
opening handshake. The server must parse at least part of this opening handshake. The server must parse at least part of this
handshake in order to obtain the necessary information to generate handshake in order to obtain the necessary information to generate
the server part of the handshake. the server part of the handshake.
skipping to change at page 29, line 26 skipping to change at page 29, line 26
1. An HTTP/1.1 or higher GET request, including a "Request-URI" 1. An HTTP/1.1 or higher GET request, including a "Request-URI"
[RFC2616] that should be interpreted as a /resource name/ [RFC2616] that should be interpreted as a /resource name/
Section 3. Section 3.
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-Version" header, with a value of 6.
5. A "Sec-WebSocket-Version" header, with a value of 5. 5. Optionally, a "Sec-WebSocket-Origin" header. This header is sent
by all browser clients. A connection attempt lacking this header
SHOULD NOT be interpreted as coming from a browser client.
6. Optionally, a "Sec-WebSocket-Protocol header, with a list of 6. Optionally, a "Sec-WebSocket-Protocol header, 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. The interpretation of this header is discussed in speak. The interpretation of this header is discussed in
Section 8.1. Section 8.1.
skipping to change at page 31, line 42 skipping to change at page 31, line 42
"dGhlIHNhbXBsZSBub25jZQ==", the server would append the "dGhlIHNhbXBsZSBub25jZQ==", the server would append the
string "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" to form the string "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" to form the
string "dGhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CA- string "dGhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CA-
C5AB0DC85B11". The server would then take the SHA-1 hash of C5AB0DC85B11". The server would then take the SHA-1 hash of
this string, giving the value 0xb3 0x7a 0x4f 0x2c 0xc0 0x62 this string, giving the value 0xb3 0x7a 0x4f 0x2c 0xc0 0x62
0x4f 0x16 0x90 0xf6 0x46 0x06 0xcf 0x38 0x59 0x45 0xb2 0xbe 0x4f 0x16 0x90 0xf6 0x46 0x06 0xcf 0x38 0x59 0x45 0xb2 0xbe
0xc4 0xea. This value is then base64-encoded, to give the 0xc4 0xea. This value is then base64-encoded, to give the
value "s3pPLMBiTxaQ9kYGzzhZRbK+xOo=", which would be returned value "s3pPLMBiTxaQ9kYGzzhZRbK+xOo=", which would be returned
in the "Sec-WebSocket-Accept" header. in the "Sec-WebSocket-Accept" header.
3. A "Sec-WebSocket-Nonce" header. The value of this header 3. Optionally, a "Sec-WebSocket-Protocol" header, with a value
MUST be a nonce consisting of a randomly selected 16-byte
value that has been base64-encoded [RFC3548]. The nonce MUST
be randomly selected randomly for each connection.
NOTE: As an example, if the randomly selected value was the
sequence of bytes 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08
0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10, the value of the
header would be "AQIDBAUGBwgJCgsMDQ4PEC==" value
4. Optionally, a "Sec-WebSocket-Protocol" header, with a value
/subprotocol/ as defined in Paragraph 2 of Section 5.2.2. /subprotocol/ as defined in Paragraph 2 of Section 5.2.2.
5. Optionally, a "Sec-WebSocket-Extensions" header, with a value 4. Optionally, a "Sec-WebSocket-Extensions" header, with a value
/extensions/ as defined in Paragraph 2 of Section 5.2.2. /extensions/ as defined in Paragraph 2 of Section 5.2.2.
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
skipping to change at page 34, line 7 skipping to change at page 33, 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. Abnormal closures 7.1. Definitions
7.1.1. Client-initiated closure 7.1.1. Close the WebSocket Connection
Certain algorithms require the user agent to *fail the WebSocket To _Close the WebSocket Connection_, an endpoint closes the
connection*. To do so, the user agent must close the WebSocket underlying TCP connection. An endpoint SHOULD use a method that
connection, and may report the problem to the user (which would be cleanly closes the TCP connection, discarding any trailing bytes that
especially useful for developers). may be received. And endpoint MAY close the connection via any means
available when necessary, such as when under attack.
As an example of how to obtain a clean closure in C using Berkeley
sockets, one would call shutdown() with SHUT_WR on the socket, call
recv() until obtaining a return value of 0 indicating that the peer
has also performed an orderly shutdown, and finally calling close()
on the socket.
7.1.2. Start the WebSocket Closing Handshake
To _start the WebSocket closing handshake_, and endpoint MUST send a
Close control frame, as described in Section 4.5.1. Upon receiving a
Close control frame, the other party sends a Close control frame in
response. Once an endpoint has both sent and received a Close
control frame, that endpoint should _Close the WebSocket Connection_
as defined in Section 7.1.1.
7.1.3. The WebSocket Connection Is Closed
When the underlying TCP connection is closed, it is said that _the
WebSocket connection is closed_. If the tcp connection was closed
after the WebSocket closing handshake was completed, the WebSocket
connection is said to have been closed _cleanly_.
7.1.4. Fail the WebSocket Connection
Certain algorithms and specifications require a user agent to _fail
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 especially useful for developers) in an appropriate manner.
Except as indicated above or as specified by the application layer
(e.g. a script using the WebSocket API), user agents SHOULD NOT close
the connection.
7.2. Abnormal closures
7.2.1. Client-initiated closure
Certain algorithms, namely during the initial handshake, require the
user agent to *fail the WebSocket connection*. To do so, the user
agent must _Close the WebSocket connection_ as previously defined,
and may report the problem to the user via an appropriate mechanism
(which would be 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.
User agents must not convey any failure information to scripts in a 7.2.2. Server-initiated closure
way that would allow a script to distinguish the following
situations:
o A server whose host name could not be resolved. Certain algorithms require or recommend that the server _abort the
WebSocket connection_ during the opening handshake. To do so, the
server must simply _close the WebSocket connection_ (Section 7.1.1).
o A server to which packets could not successfully be routed. 7.3. Normal closure of connections
o A server that refused the connection on the specified port. Servers MAY close the WebSocket connection whenever desired. User
agents SHOULD NOT close the WebSocket connection arbitrarily. In
either case, an endpoint initiates a closure by following the
procedures to _start the WebSocket closing handshake_
(Section 7.1.2).
o A server that did not complete the opening handshake (e.g. because 7.4. Status codes
it was not a WebSocket server).
o A WebSocket server that sent a correct opening handshake, but that When closing an established connection (e.g. when sending a Close
specified options that caused the client to drop the connection frame, after the handshake has completed), an endpoint MAY indicate a
(e.g. the server specified an origin that differed from the reason for closure. The interpretation of this reason by an
script's). endpoint, and the action an endpoint should take given this reason,
are left undefined by this specification. This specification defines
a set of pre-defined status codes, and specifies which ranges may be
used by extensions, frameworks, and end applications. The status
code and any associated textual message are optional components of a
Close frame.
o A WebSocket server that abruptly closed the connection after 7.4.1. Defined Status Codes
successfully completing the opening handshake.
7.1.2. Server-initiated closure Endpoints MAY use the following pre-defined status codes when sending
a Close frame.
Certain algorithms require or recommend that the server *abort the 1000
WebSocket connection* during the opening handshake. To do so, the
server must simply close the WebSocket connection.
7.2. Normal closure of connections 1000 indicates a normal closure, meaning whatever purpose the
connection was established for has been fulfilled.
To *close the WebSocket connection*, the user agent MUST first send a 1001
Close control frame, as described in Section 4.5.1. Upon receiving a
Close control frame, the other party sends a matching Close control
frame. Once an endpoint has sent or received an acknowledgement of a
Close control frame, that endpoint must close the TCP connection,
using whatever mechanism possible (e.g. either the TCP RST or FIN
mechanisms). Whether the user agent or the server closes the
connection first, it is said that the *WebSocket connection is
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 1001 indicates that an endpoint is "going away", such as a server
agents should not close the WebSocket connection arbitrarily. going down, or a browser having navigated away from a page.
1002
1002 indicates that an endpoint is terminating the connection due
to a protocol error.
1003
1003 indicates that an endpoint is terminating the connection
because it has received a type of data it cannot accept (e.g. an
endpoint that understands only text data may send this if it
receives a binary message.)
1004
1004 indicates that an endpoint is terminating the connection
because it has received a message that is too large.
7.4.2. Reserved status code ranges
0-999
Status codes in the range 0-999 are not used.
1000-1999
Status codes in the range 1000-1999 are reserved for definition by
this protocol.
2000-2999
Status codes in the range 2000-2999 are reserved for use by
extensions.
3000-3999
Status codes in the range 3000-3999 MAY be used by libraries and
frameworks. The interpretation of these codes is undefined by
this protocol. End applications MUST NOT use status codes in this
range.
4000-4999
Status codes in the range 4000-4999 MAY be used by application
code. The interpretaion of these codes is undefined by this
protocol.
8. Extensions 8. Extensions
WebSocket clients MAY request extensions to this specification, and WebSocket clients MAY request extensions to this specification, and
WebSocket servers MAY accept some or all extensions requested by the WebSocket servers MAY accept some or all extensions requested by the
client. A server MUST NOT respond with any extension not requested client. A server MUST NOT respond with any extension not requested
by the client. If extension parameters are included in negotiations by the client. If extension parameters are included in negotiations
between the client and the server, those parameters MUST be chosen in between the client and the server, those parameters MUST be chosen in
accordance with the specification of the extension to which the accordance with the specification of the extension to which the
parameters apply. parameters apply.
skipping to change at page 40, line 5 skipping to change at page 40, line 41
does not correspond to the values the server is expecting (e.g. does not correspond to the values the server is expecting (e.g.
incorrect path or origin), the server should just disconnect. It is incorrect path or origin), the server should just disconnect. It is
always safe to disconnect. always safe to disconnect.
The biggest security risk when sending text data using this protocol The biggest security risk when sending text data using this protocol
is sending data using the wrong encoding. If an attacker can trick is sending data using the wrong encoding. If an attacker can trick
the server into sending data encoded as ISO-8859-1 verbatim (for the server into sending data encoded as ISO-8859-1 verbatim (for
instance), rather than encoded as UTF-8, then the attacker could instance), rather than encoded as UTF-8, then the attacker could
inject arbitrary frames into the data stream. inject arbitrary frames into the data stream.
In addition to endpoints being the target of attacks via WebSockets,
other parts of web infrastructure, such as proxies, may be the
subject of an attack. In particular, an intermediary may interpret a
WebSocket message from a client as a request, and a message from the
server as a response to that request. For instance, an attacker
could get a browser to establish a connection to its server, get the
browser to send a message that looks to an intermediary like a GET
request for a common piece of JavaScript on another domain, and send
back a message that is interpreted as a cacheable response to that
request, thus poisioning the cache for other users. To prevent this
attack, messages sent from clients are masked on the wire with a 32-
bit value, to prevent an attacker from controlling the bits on the
wire and thus lessen the probability of an attacker being able to
construct a message that can be misinterpreted by a proxy as a non-
WebSocket request.
10. IANA considerations 10. IANA considerations
10.1. Registration of ws: scheme 10.1. Registration of ws: scheme
A |ws:| URL identifies a WebSocket server and resource name. A |ws:| URI identifies a WebSocket server and resource name.
URI scheme name. URI scheme name.
ws ws
Status. Status.
Permanent. Permanent.
URI scheme syntax. URI scheme syntax.
In ABNF terms using the terminals from the URI specifications: In ABNF terms using the terminals from the URI specifications:
[RFC5234] [RFC3986] [RFC5234] [RFC3986]
skipping to change at page 41, line 19 skipping to change at page 43, line 19
Ian Hickson <ian@hixie.ch> Ian Hickson <ian@hixie.ch>
Author/Change controller. Author/Change controller.
Ian Hickson <ian@hixie.ch> Ian Hickson <ian@hixie.ch>
References. References.
This document. This document.
10.2. Registration of wss: scheme 10.2. Registration of wss: scheme
A |wss:| URL identifies a WebSocket server and resource name, and A |wss:| URI identifies a WebSocket server and resource name, and
indicates that traffic over that connection is to be encrypted. indicates that traffic over that connection is to be encrypted.
URI scheme name. URI scheme name.
wss wss
Status. Status.
Permanent. Permanent.
URI scheme syntax. URI scheme syntax.
In ABNF terms using the terminals from the URI specifications: In ABNF terms using the terminals from the URI specifications:
skipping to change at page 42, line 38 skipping to change at page 44, line 38
Author/Change controller. Author/Change controller.
Ian Hickson <ian@hixie.ch> Ian Hickson <ian@hixie.ch>
Contact. Contact.
Ian Hickson <ian@hixie.ch> Ian Hickson <ian@hixie.ch>
References. References.
This document. This document.
10.4. Sec-WebSocket-Key and Sec-WebSocket-Nonce 10.4. Sec-WebSocket-Key
This section describes two header fields for registration in the This section describes a header field for registration in the
Permanent Message Header Field Registry. [RFC3864] Permanent Message Header Field Registry. [RFC3864]
Header field name Header field name
Sec-WebSocket-Key Sec-WebSocket-Key
Applicable protocol Applicable protocol
http http
Status Status
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.
Header field name The |Sec-WebSocket-Key| header is used in the WebSocket handshake.
Sec-WebSocket-Nonce It is sent from the client to the server to provide part of the
information used by the server to prove that it received a valid
Applicable protocol WebSocket handshake. This helps ensure that the server does not
http accept connections from non-WebSocket clients (e.g. HTTP clients)
that are being abused to send data to unsuspecting WebSocket servers.
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-Key| and |Sec-WebSocket-Nonce| headers are used in
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
it received a valid WebSocket handshake. This helps ensure that the
server does not accept connections from non-Web-Socket clients (e.g.
HTTP clients) that are being abused to send data to unsuspecting
WebSocket servers.
10.5. Sec-WebSocket-Extensions 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-Extensions Sec-WebSocket-Extensions
Applicable protocol Applicable protocol
skipping to change at page 47, line 29 skipping to change at page 49, line 29
o A /secure/ flag, which is true if the connection is to be o A /secure/ flag, which is true if the connection is to be
encrypted, and false otherwise. encrypted, and false otherwise.
o An ASCII serialization of an origin that is being made responsible o An ASCII serialization of an origin that is being made responsible
for the connection. [I-D.ietf-websec-origin] for the connection. [I-D.ietf-websec-origin]
o Optionally a string identifying a protocol that is to be layered o Optionally a string identifying a protocol that is to be layered
over the WebSocket connection. over the WebSocket connection.
The /host/, /port/, /resource name/, and /secure/ flag are usually The /host/, /port/, /resource name/, and /secure/ flag are usually
obtained from a URL using the steps to parse a WebSocket URL's obtained from a URI using the steps to parse a WebSocket URI's
components. These steps fail if the URL does not specify a components. These steps fail if the URI does not specify a
WebSocket. WebSocket.
If a connection can be established, then it is said that the If a connection can be established, then it is said that the
"WebSocket connection is established". "WebSocket connection is established".
If at any time the connection is to be closed, then the specification If at any time the connection is to be closed, then the specification
needs to use the "close the WebSocket connection" algorithm. needs to use the "close the WebSocket connection" algorithm.
When the connection is closed, for any reason including failure to When the connection is closed, for any reason including failure to
establish the connection in the first place, it is said that the establish the connection in the first place, it is said that the
skipping to change at page 48, line 12 skipping to change at page 50, line 12
To send some text /data/ to an open connection, the specification To send some text /data/ to an open connection, the specification
needs to "send /data/ using the WebSocket". needs to "send /data/ using the WebSocket".
12. Acknowledgements 12. Acknowledgements
Special thanks are due to Ian Hickson, who was the original author Special thanks are due to Ian Hickson, who was the original author
and editor of this protocol. The initial design of this and editor of this protocol. The initial design of this
specification benefitted from the participation of many people in the specification benefitted from the participation of many people in the
WHATWG and WHATWG mailing list. Contributions to that specification WHATWG and WHATWG mailing list. Contributions to that specification
are not tracked by section, but a list of all who contributed to that are not tracked by section, but a list of all who contributed to that
specification is given in the WHATWG HTML specification. [HTML] specification is given in the WHATWG HTML specification at
http://whatwg.org/html5.
Special thanks also to John Tamplin for providing a significant Special thanks also to John Tamplin for providing a significant
amount of text for the Data Framing section of this specification. amount of text for the Data Framing section of this specification.
Special thanks also to Adam Barth for providing a significant amount Special thanks also to Adam Barth for providing a significant amount
of text and background research for the Data Masking section of this of text and background research for the Data Masking section of this
specification. specification.
13. Normative References 13. Appendix: List of Changes
[HTML] Hickson, I., "HTML", August 2010, This section is not normative. This section was added at the request
<http://whatwg.org/html5>. of the chairs to help track changes between versions. This section
will be removed from the final version of this document.
13.1. Changes from -05 to -06
Two major areas were changed in this draft. The closing handshake
was clarified and re-written to add in terminology matching the API
specification. The close frame was given an optional status code to
indicate closure reason, and the notion of a body indicating which
side initiated the close removed. Aside from this, many areas were
clarified in areas previously ambiguous, though the meaning should
remain consistent with the intent of previous drafts. Certain other
material changes that are not as large as those previously mentioned
are listed below, though for a complete list readers are reminded
that a tool is available to diff two versions at
http://tools.ietf.org/tools/rfcdiff/. The list below is my attempt
at a changelog, not an authoritative guarantee, plese use the diff
tool for a complete list.
o Clarified that Sec-WebSocket-Origin is optional for non-browser
clients.
o Clarified the semantics of the closing handshake to be that the
connection is closed when an endpoint has both sent and received a
close frame.
o Changed text around final HTTP responses and the WebSocket
handshake.
o Removed Sec-WebSocket-Nonce
o Attempted to convert use of URL to URI terminology. (Ticket 41)
o Attempted to resolve Ticket 42 re: HTML spec reference.
o Edited potentially misleadin text around the word "even" in
Section 1.6 and what applied to XHR vs more broadly.
o Removed non-material text from 1.8 about establishing a
connection.
o Clarified text in the section about fragmentation (4.4). No
material changes, clarification only.
o Clarified that control frames (4.5) may be interjected in the
middle of a fragmented message.
o Clarified what was meant by the body of a close frame.
o Clarified the intent in 5.1 that there be only one connection in
CONNECTING state.
o Cleaned 1.5 up to note that compression was already introduced in
the spec, left in multiplexing as a future definition.
o Randomly selected randomly - typo fix.
o Added a change log in the appendix.
o Included in security considerations a description of the attack
presented by Adam Barth.
o Changed some referneces from Web-Socket to WebSocket
o Clarified in 3.1 that only ws and wss are valid options, and that
other schemes should result in a failure.
o Various cleanups around terminology of "host", "endpoint", and
"user agent".
o Defined status codes and reserved ranges for close frames.
o Added text that a TCP connection should be shut down cleanly.
o Clarified whether the upgrade header exactly equaled upgrade or
contained an upgrade token.
14. Normative References
[ANSI.X3-4.1986] [ANSI.X3-4.1986]
American National Standards Institute, "Coded Character American National Standards Institute, "Coded Character
Set - 7-bit American Standard Code for Information Set - 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
[FIPS.180-2.2002] [FIPS.180-2.2002]
National Institute of Standards and Technology, "Secure National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-2, August 2002, <http:// Hash Standard", FIPS PUB 180-2, August 2002, <http://
csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf>. csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf>.
 End of changes. 99 change blocks. 
234 lines changed or deleted 418 lines changed or added

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