Network Working Group I. Hickson Internet-Draft Google, Inc. Intended status: Standards Track October 23, 2009 Expires: April 26, 2010 The Web Socket protocol draft-hixie-thewebsocketprotocol-54 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 26, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Hickson Expires April 26, 2010 [Page 1]

Internet-Draft The Web Socket protocol October 2009 Abstract The Web Sockets protocol enables two-way communication between a user agent running untrusted code running in a controlled environment to a remote host that has opted-in to communications from that code. The protocol consists of an initial handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g. using XMLHttpRequest or <iframe>s and long polling). Hickson Expires April 26, 2010 [Page 2]

Internet-Draft The Web Socket protocol October 2009 Author's note This document is automatically generated from the same source document as the HTML5 specification. [HTML5] Please send feedback to either the hybi@ietf.org list or the whatwg@whatwg.org list. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Protocol overview . . . . . . . . . . . . . . . . . . . . 4 1.3. Design philosophy . . . . . . . . . . . . . . . . . . . . 6 1.4. Security model . . . . . . . . . . . . . . . . . . . . . . 6 1.5. Relationship to TCP/IP and HTTP . . . . . . . . . . . . . 7 1.6. Establishing a connection . . . . . . . . . . . . . . . . 7 2. Conformance requirements . . . . . . . . . . . . . . . . . . . 9 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 9 3. Web Socket URLs . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Parsing Web Socket URLs . . . . . . . . . . . . . . . . . 10 3.2. Constructing Web Socket URLs . . . . . . . . . . . . . . . 11 4. Client-side requirements . . . . . . . . . . . . . . . . . . . 12 4.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. Data framing . . . . . . . . . . . . . . . . . . . . . . . 19 4.3. Closing the connection . . . . . . . . . . . . . . . . . . 21 4.4. Handling errors in UTF-8 . . . . . . . . . . . . . . . . . 21 5. Server-side requirements . . . . . . . . . . . . . . . . . . . 22 5.1. Minimal handshake . . . . . . . . . . . . . . . . . . . . 22 5.2. Handshake details . . . . . . . . . . . . . . . . . . . . 23 5.3. Data framing . . . . . . . . . . . . . . . . . . . . . . . 24 6. Closing the connection . . . . . . . . . . . . . . . . . . . . 26 7. Security considerations . . . . . . . . . . . . . . . . . . . 27 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 28 8.1. Registration of ws: scheme . . . . . . . . . . . . . . . . 28 8.2. Registration of wss: scheme . . . . . . . . . . . . . . . 29 8.3. Registration of the "WebSocket" HTTP Upgrade keyword . . . 30 8.4. WebSocket-Origin . . . . . . . . . . . . . . . . . . . . . 30 8.5. WebSocket-Protocol . . . . . . . . . . . . . . . . . . . . 31 8.6. WebSocket-Location . . . . . . . . . . . . . . . . . . . . 32 9. Using the Web Socket protocol from other specifications . . . 33 10. Normative References . . . . . . . . . . . . . . . . . . . . . 34 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 36 Hickson Expires April 26, 2010 [Page 3]

Internet-Draft The Web Socket protocol October 2009 1 . Introduction 1.1 . Background WSAPI] The same technique can be used for a variety of Web applications: games, stock tickers, multiuser applications with simultaneous editing, user interfaces exposing server-side services in real time, etc. 1.2 . Protocol overview Hickson Expires April 26, 2010 [Page 4]

Internet-Draft The Web Socket protocol October 2009 The handshake from the server looks as follows: HTTP/1.1 101 Web Socket Protocol Handshake Upgrade: WebSocket Connection: Upgrade WebSocket-Origin: http://example.com WebSocket-Location: ws://example.com/demo WebSocket-Protocol: sample The first three lines in each case are hard-coded (the exact case and order matters); the remainder are an unordered ASCII case-insensitive set of fields, one per line, that match the following non-normative ABNF: [RFC5234] field = 1*name-char colon [ space ] *any-char cr lf colon = %x003A ; U+003A COLON (:) space = %x0020 ; U+0020 SPACE cr = %x000D ; U+000D CARRIAGE RETURN (CR) lf = %x000A ; U+000A LINE FEED (LF) name-char = %x0000-0009 / %x000B-000C / %x000E-0039 / %x003B-10FFFF ; a Unicode character other than U+000A LINE FEED (LF), U+000D CARRIAGE RETURN (CR), or U+003A COLON (:) any-char = %x0000-0009 / %x000B-000C / %x000E-10FFFF ; a Unicode character other than U+000A LINE FEED (LF) or U+000D CARRIAGE RETURN (CR) Lines that don't match the above production cause the connection to be aborted. Once the client and server have both sent their handshakes, and if the handshake was successful, then the data transfer part starts. This is a two-way communication channel where each side can, independently from the other, send data at will. Data is sent in the form of UTF-8 text. Each frame of data starts with a 0x00 byte and ends with a 0xFF byte, with the UTF-8 text in between. The Web Socket protocol uses this framing so that specifications that use the Web Socket protocol can expose such connections using an event-based mechanism instead of requiring users of those specifications to implement buffering and piecing together of messages manually. The protocol is designed to support other frame types in future. Instead of the 0x00 byte, other bytes might in future be defined. Frames denoted by bytes that do not have the high bit set (0x00 to 0x7F) are treated as described above (a stream of bytes terminated by 0xFF). Frames denoted by bytes that have the high bit set (0x80 to Hickson Expires April 26, 2010 [Page 5]

Internet-Draft The Web Socket protocol October 2009 0xFF) have a leading length indicator, which is encoded as a series of 7-bit bytes stored in octets with the 8th bit being set for all but the last byte. The remainder of the frame is then as much data as was specified. The following diagrams summarise the protocol: Handshake | \|/ Frame type byte <-------------------------------------. | | | | `-- (0x00 to 0x7F) --> Data... --> 0xFF -->-+ | | `-- (0x80 to 0xFF) --> Length --> Data... ------->-' 1.3 . Design philosophy 1.4 . Security model Hickson Expires April 26, 2010 [Page 6]

Internet-Draft The Web Socket protocol October 2009 Socket protocol is used directly (not from a Web page), the origin model is not useful, as the client can provide any arbitrary origin string. This protocol is intended to fail to establish a connection with servers of pre-existing protocols like SMTP or HTTP, while allowing HTTP servers to opt-in to supporting this protocol if desired. This is achieved by having a strict and elaborate handshake, and by limiting the data that can be inserted into the connection before the handshake is finished (thus limiting how much the server can be influenced). 1.5 . Relationship to TCP/IP and HTTP 1.6 . Establishing a connection Hickson Expires April 26, 2010 [Page 7]

Internet-Draft The Web Socket protocol October 2009 set of hosts for Web Socket connections separate from the HTTP servers is probably easier to manage. Hickson Expires April 26, 2010 [Page 8]

Internet-Draft The Web Socket protocol October 2009 2 . Conformance requirements RFC2119. For readability, these words do not appear in all uppercase letters in this specification. [RFC2119] Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("must", "should", "may", etc) used in introducing the algorithm. Conformance requirements phrased as algorithms or specific steps may be implemented in any manner, so long as the end result is equivalent. (In particular, the algorithms defined in this specification are intended to be easy to follow, and not intended to be performant.) Implementations may impose implementation-specific limits on otherwise unconstrained inputs, e.g. to prevent denial of service attacks, to guard against running out of memory, or to work around platform-specific limitations. The conformance classes defined by this specification are user agents and servers. 2.1 . Terminology HTML5] Hickson Expires April 26, 2010 [Page 9]

Internet-Draft The Web Socket protocol October 2009 3 . Web Socket URLs 3.1 . Parsing Web Socket URLs WEBADDRESSES] 3. Resolve the /url/ string using the resolve a Web address algorithm defined by the Web addresses specification, with the URL character encoding set to UTF-8. [WEBADDRESSES] [RFC3629] NOTE: It doesn't matter what it is resolved relative to, since we already know it is an absolute URL at this point. 4. If /url/ does not have a <scheme> component whose value is either "ws" or "wss", when compared in an ASCII case-insensitive manner, then fail this algorithm. 5. If the <scheme> component of /url/ is "ws", set /secure/ to false; otherwise, the <scheme> component is "wss", set /secure/ to true. 6. Let /host/ be the value of the <host> component of /url/, converted to ASCII lowercase. 7. If /url/ has a <port> component, then let /port/ be that component's value; otherwise, there is no explicit /port/. 8. If there is no explicit /port/, then: if /secure/ is false, let /port/ be 80, otherwise let /port/ be 443. 9. Let /resource name/ be the value of the <path> component (which might be empty) of /url/. 10. If /resource name/ is the empty string, set it to a single character U+002F SOLIDUS (/). 11. If /url/ has a <query> component, then append a single U+003F QUESTION MARK character (?) to /resource name/, followed by the value of the <query> component. Hickson Expires April 26, 2010 [Page 10]

Internet-Draft The Web Socket protocol October 2009 12. Return /host/, /port/, /resource name/, and /secure/. 3.2 . Constructing Web Socket URLs Hickson Expires April 26, 2010 [Page 11]

Internet-Draft The Web Socket protocol October 2009 4 . Client-side requirements 4.1 . Handshake ORIGIN] 1. If the user agent already has a Web Socket connection to the remote host (IP address) identified by /host/, even if known by another name, wait until that connection has been established or for that connection to have failed. NOTE: This makes it harder for a script to perform a denial of service attack by just opening a large number of Web Socket connections to a remote host. NOTE: There is no limit to the number of established Web Socket connections a user agent can have with a single remote host. Servers can refuse to connect users with an excessive number of connections, or disconnect resource-hogging users when suffering high load. 2. _Connect_: If the user agent is configured to use a proxy when using the Web Socket protocol to connect to host /host/ and/or port /port/, then connect to that proxy and ask it to open a TCP/IP connection to the host given by /host/ and the port given by /port/. EXAMPLE: For example, if the user agent uses an HTTP proxy for all traffic, then if it was to try to connect to port 80 on server example.com, it might send the following lines to the proxy server: CONNECT example.com:80 HTTP/1.1 Host: example.com If there was a password, the connection might look like: Hickson Expires April 26, 2010 [Page 12]

Internet-Draft The Web Socket protocol October 2009 CONNECT example.com:80 HTTP/1.1 Host: example.com Proxy-authorization: Basic ZWRuYW1vZGU6bm9jYXBlcyE= Otherwise, if the user agent is not configured to use a proxy, then open a TCP/IP connection to the host given by /host/ and the port given by /port/. NOTE: Implementations that do not expose explicit UI for selecting a proxy for Web Socket connections separate from other proxies are encouraged to use a SOCKS proxy for Web Socket connections, if available, or failing that, to prefer the proxy configured for HTTPS connections over the proxy configured for HTTP connections. For the purpose of proxy autoconfiguration scripts, the URL to pass the function must be constructed from /host/, /port/, /resource name/, and the /secure/ flag using the steps to construct a Web Socket URL. NOTE: The WebSocket protocol can be identified in proxy autoconfiguration scripts from the scheme ("ws:" for unencrypted connections and "wss:" for encrypted connections). 3. If the connection could not be opened, then fail the Web Socket connection and abort these steps. 4. If /secure/ is true, perform a TLS handshake over the connection. If this fails (e.g. the server's certificate could not be verified), then fail the Web Socket connection and abort these steps. Otherwise, all further communication on this channel must run through the encrypted tunnel. [RFC2246] 5. Send the following bytes to the remote side (the server): 47 45 54 20 Send the /resource name/ value, encoded as US-ASCII. Send the following bytes: 20 48 54 54 50 2F 31 2E 31 0D 0A 55 70 67 72 61 64 65 3A 20 57 65 62 53 6F 63 6B 65 74 0D 0A 43 6F 6E 6E 65 63 74 69 6F 6E 3A 20 55 70 67 72 61 64 65 0D 0A NOTE: The string "GET ", the path, " HTTP/1.1", CRLF, the string "Upgrade: WebSocket", CRLF, and the string "Connection: Hickson Expires April 26, 2010 [Page 13]

Internet-Draft The Web Socket protocol October 2009 Upgrade", CRLF. 6. Send the following bytes: 48 6F 73 74 3A 20 Send the /host/ value, converted to ASCII lowercase, and encoded as US-ASCII. If /secure/ is false, and /port/ is not 80, or if /secure/ is true, and /port/ is not 443, then send an 0x3A byte (ASCII :) followed by the value of /port/, expressed as a base-ten integer, encoded as US-ASCII. Send the following bytes: 0D 0A NOTE: The string "Host: ", the host, and CRLF. 7. Send the following bytes: 4F 72 69 67 69 6E 3A 20 Send the /origin/ value, converted to ASCII lowercase, encoded as US-ASCII. [ORIGIN] NOTE: The /origin/ value is a string that was passed to this algorithm. Send the following bytes: 0D 0A NOTE: The string "Origin: ", the origin, and CRLF. 8. If there is no /protocol/, then skip this step. Otherwise, send the following bytes: 57 65 62 53 6F 63 6B 65 74 2D 50 72 6F 74 6F 63 6F 6C 3A 20 Send the /protocol/ value, encoded as US-ASCII. Send the following bytes: 0d 0a Hickson Expires April 26, 2010 [Page 14]

Internet-Draft The Web Socket protocol October 2009 NOTE: The string "WebSocket-Protocol: ", the protocol, and CRLF. 9. If the client has any cookies that would be relevant to a resource accessed over HTTP, if /secure/ is false, or HTTPS, if it is true, on host /host/, port /port/, with /resource name/ as the path (and possibly query parameters), then HTTP headers that would be appropriate for that information should be sent at this point. [RFC2616] [RFC2109] [RFC2965] Each header must be on a line of its own (each ending with a CR LF sequence). For the purposes of this step, each header must not be split into multiple lines (despite HTTP otherwise allowing this with continuation lines). 10. Send the following bytes: 0d 0a NOTE: Just a CRLF (a blank line). 11. Read bytes from the server until either the connection closes, or a 0x0A byte is read. Let /header/ be these bytes, including the 0x0A byte. If /header/ is not at least two bytes long, or if the last two bytes aren't 0x0D and 0x0A respectively, then fail the Web Socket connection and abort these steps. User agents may apply a timeout to this step, failing the Web Socket connection if the server does not send back data in a suitable time period. 12. If /header/ consists of 44 bytes that exactly match the following, then let /mode/ be _normal_. 48 54 54 50 2F 31 2E 31 20 31 30 31 20 57 65 62 20 53 6F 63 6B 65 74 20 50 72 6F 74 6F 63 6F 6C 20 48 61 6E 64 73 68 61 6B 65 0D 0A NOTE: The string "HTTP/1.1 101 Web Socket Protocol Handshake" followed by a CRLF pair. NOTE: Note that this means that if a server responds with a Web Socket handshake but with the string "HTTP/1.0" or "HTTP/1.2" at the front, a normal Web Socket connection will not be established. Otherwise, let /code/ be the substring of /header/ that starts Hickson Expires April 26, 2010 [Page 15]

Internet-Draft The Web Socket protocol October 2009 from the byte after the first 0x20 byte, and ends with the byte before the second 0x20 byte. If there are not at least two 0x20 bytes in /header/, then fail the Web Socket connection and abort these steps. If /code/, interpreted as ASCII, is "407", then either close the connection and jump back to step 2, providing appropriate authentication information, or fail the Web Socket connection. 407 is the code used by HTTP meaning "Proxy Authentication Required". User agents that support proxy authentication must interpret the response as defined by HTTP (e.g. to find and interpret the |Proxy-Authenticate| header). Otherwise, fail the Web Socket connection and abort these steps. 13. If /mode/ is _normal_, then read 41 bytes from the server. If the connection closes before 41 bytes are received, or if the 41 bytes aren't exactly equal to the following bytes, then fail the Web Socket connection and abort these steps. 55 70 67 72 61 64 65 3A 20 57 65 62 53 6F 63 6B 65 74 0D 0A 43 6F 6E 6E 65 63 74 69 6F 6E 3A 20 55 70 67 72 61 64 65 0D 0A NOTE: The string "Upgrade: WebSocket", CRLF, the string "Connection: Upgrade", CRLF. User agents may apply a timeout to this step, failing the Web Socket connection if the server does not respond with the above bytes within a suitable time period. 14. Let /headers/ be a list of name-value pairs, initially empty. 15. _Header_: Let /name/ and /value/ be empty byte arrays. 16. Read a byte from the server. If the connection closes before this byte is received, then fail the Web Socket connection and abort these steps. Otherwise, handle the byte as described in the appropriate entry below: -> If the byte is 0x0D (ASCII CR) If the /name/ byte array is empty, then jump to the headers processing step. Otherwise, fail the Web Socket connection and abort these steps. Hickson Expires April 26, 2010 [Page 16]

Internet-Draft The Web Socket protocol October 2009 -> If the byte is 0x0A (ASCII LF) Fail the Web Socket connection and abort these steps. -> If the byte is 0x3A (ASCII :) Move on to the next step. -> If the byte is in the range 0x41 to 0x5A (ASCII A-Z) Append a byte whose value is the byte's value plus 0x20 to the /name/ byte array and redo this step for the next byte. -> Otherwise Append the byte to the /name/ byte array and redo this step for the next byte. NOTE: This reads a header name, terminated by a colon, converting upper-case ASCII letters to lowercase, and aborting if a stray CR or LF is found. 17. Read a byte from the server. If the connection closes before this byte is received, then fail the Web Socket connection and abort these steps. Otherwise, handle the byte as described in the appropriate entry below: -> If the byte is 0x20 (ASCII space) Ignore the byte and move on to the next step. -> Otherwise Treat the byte as described by the list in the next step, then move on to that next step for real. NOTE: This skips past a space character after the colon, if necessary. 18. Read a byte from the server. If the connection closes before this byte is received, then fail the Web Socket connection and abort these steps. Otherwise, handle the byte as described in the appropriate entry below: -> If the byte is 0x0D (ASCII CR) Move on to the next step. Hickson Expires April 26, 2010 [Page 17]

Internet-Draft The Web Socket protocol October 2009 -> If the byte is 0x0A (ASCII LF) Fail the Web Socket connection and abort these steps. -> Otherwise Append the byte to the /value/ byte array and redo this step for the next byte. NOTE: This reads a header value, terminated by a CRLF. 19. Read a byte from the server. If the connection closes before this byte is received, or if the byte is not a 0x0A byte (ASCII LF), then fail the Web Socket connection and abort these steps. NOTE: This skips past the LF byte of the CRLF after the header. 20. Append an entry to the /headers/ list that has the name given by the string obtained by interpreting the /name/ byte array as a UTF-8 byte stream and the value given by the string obtained by interpreting the /value/ byte array as a UTF-8 byte stream. 21. Return to the "Header" step above. 22. _Headers processing_: Read a byte from the server. If the connection closes before this byte is received, or if the byte is not a 0x0A byte (ASCII LF), then fail the Web Socket connection and abort these steps. NOTE: This skips past the LF byte of the CRLF after the blank line after the headers. 23. If /mode/ is _normal_, then: If there is not exactly one entry in the /headers/ list whose name is "websocket-origin", or if there is not exactly one entry in the /headers/ list whose name is "websocket-location", or if the /protocol/ was specified but there is not exactly one entry in the /headers/ list whose name is "websocket-protocol", or if there are any entries in the /headers/ list whose names are the empty string, then fail the Web Socket connection and abort these steps. Otherwise, handle each entry in the /headers/ list as follows: -> If the entry's name is "websocket-origin" If the value is not exactly equal to /origin/, converted to ASCII lowercase, then fail the Web Socket connection and abort these steps. [ORIGIN] Hickson Expires April 26, 2010 [Page 18]

Internet-Draft The Web Socket protocol October 2009 -> If the entry's name is "websocket-location" If the value is not exactly equal to a string obtained from the steps to construct a Web Socket URL from /host/, /port/, /resource name/, and the /secure/ flag, then fail the Web Socket connection and abort these steps. -> If the entry's name is "websocket-protocol" If there was a /protocol/ specified, and the value is not exactly equal to /protocol/, then fail the Web Socket connection and abort these steps. (If no /protocol/ was specified, the header is ignored.) -> If the entry's name is "set-cookie" or "set-cookie2" or another cookie-related header name Handle the cookie as defined by the appropriate specification, with the resource being the one with the host /host/, the port /port/, the path (and possibly query parameters) /resource name/, and the scheme |http| if /secure/ is false and |https| if /secure/ is true. [RFC2109] [RFC2965] -> Any other name Ignore it. 24. The *Web Socket connection is established*. Now the user agent must send and receive to and from the connection as described in the next section. 4.2 . Data framing Hickson Expires April 26, 2010 [Page 19]

Internet-Draft The Web Socket protocol October 2009 1. Let /length/ be zero. 2. _Length_: Read a byte, let /b/ be that byte. 3. Let /b_v/ be integer corresponding to the low 7 bits of /b/ (the value you would get by _and_ing /b/ with 0x7F). 4. Multiply /length/ by 128, add /b_v/ to that result, and store the final result in /length/. 5. If the high-order bit of /b/ is set (i.e. if /b/ _and_ed with 0x80 returns 0x80), then return to the step above labeled _length_. 6. Read /length/ bytes. 7. Discard the read bytes. If the high-order bit of the /frame type/ byte is _not_ set (i.e. if /frame type/ _and_ed with 0x80 returns 0x00) Run these steps. If at any point during these steps a read is attempted but fails because the Web Socket connection is closed, then abort. 1. Let /raw data/ be an empty byte array. 2. _Data_: Read a byte, let /b/ be that byte. If the client runs out of resources for buffering the incoming data, or hits an artificial resource limit intended to avoid resource starvation, then it must fail the Web Socket connection and abort these steps. 3. If /b/ is not 0xFF, then append /b/ to /raw data/ and return to the previous step (labeled _data_). 4. Interpret /raw data/ as a UTF-8 string, and store that string in /data/. 5. If /frame type/ is 0x00, then *a message has been received* with text /data/. Otherwise, discard the data. 3. Return to the first step to read the next byte. If the user agent is faced with content that is too large to be handled appropriately, then it must fail the Web Socket connection. Once a Web Socket connection is established, the user agent must use Hickson Expires April 26, 2010 [Page 20]

Internet-Draft The Web Socket protocol October 2009 the following steps to *send /data/ using the Web Socket*: 1. Send a 0x00 byte to the server. 2. Encode /data/ using UTF-8 and send the resulting byte stream to the server. 3. Send a 0xFF byte to the server. If at any point there is a fatal problem with sending data to the server, the user agent must fail the Web Socket connection. 4.3 . Closing the connection 4.4 . Handling errors in UTF-8 Hickson Expires April 26, 2010 [Page 21]

Internet-Draft The Web Socket protocol October 2009 5 . Server-side requirements 5.1 . Minimal handshake ORIGIN] For instance: WebSocket-Origin: http://example.com Send the string "WebSocket-Location" followed by a U+003A COLON (:) and a U+0020 SPACE, followed by the URL of the Web Socket script, followed by a CRLF pair (0x0D 0x0A). For instance: WebSocket-Location: ws://example.com/demo NOTE: Do not include the port if it is the default port for Web Socket protocol connections of the type in question (80 for unencrypted connections and 443 for encrypted connections). Send another CRLF pair (0x0D 0x0A). Read data from the client until four bytes 0x0D 0x0A 0x0D 0x0A are read. This data must either be discarded or handled as described in the following section describing the handshake details. If the connection isn't dropped at this point, go to the data framing section. Hickson Expires April 26, 2010 [Page 22]

Internet-Draft The Web Socket protocol October 2009 NOTE: User agents will drop the connection after the handshake if the values returned for |WebSocket-Origin| and |WebSocket-Location| don't match what the client sent to the server, to protect the server from third-party scripts. This is why the server has to send these strings: to confirm which origins and URLs the server is willing to service. 5.2 . Handshake details Hickson Expires April 26, 2010 [Page 23]

Internet-Draft The Web Socket protocol October 2009 If the server supports connections from more than one origin, then the server should echo the value of this field in the initial handshake, on the |WebSocket-Origin| line. Other fields Other fields can be used, such as "Cookie", for authentication purposes. Any fields that lack the colon-space separator should be discarded and may cause the server to disconnect. 5.3 . Data framing Hickson Expires April 26, 2010 [Page 24]

Internet-Draft The Web Socket protocol October 2009 3. Send a 0xFF byte to the client to indicate the end of the message. Hickson Expires April 26, 2010 [Page 25]

Internet-Draft The Web Socket protocol October 2009 6 . Closing the connection Hickson Expires April 26, 2010 [Page 26]

Internet-Draft The Web Socket protocol October 2009 7 . Security considerations Hickson Expires April 26, 2010 [Page 27]

Internet-Draft The Web Socket protocol October 2009 8 . IANA considerations 8.1 . Registration of ws: scheme RFC5234] [RFC3986] "ws" ":" hier-part [ "?" query ] The path and query components form the resource name sent to the server to identify the kind of service desired. Other components have the meanings described in RFC3986. URI scheme semantics. The only operation for this scheme is to open a connection using the Web Socket protocol. Encoding considerations. Characters in the host component that are excluded by the syntax defined above must be converted from Unicode to ASCII by applying the IDNA ToASCII algorithm to the Unicode host name, with both the AllowUnassigned and UseSTD3ASCIIRules flags set, and using the result of this algorithm as the host in the URI. [RFC3490] Characters in other components that are excluded by the syntax defined above must be converted from Unicode to ASCII by first encoding the characters as UTF-8 and then replacing the corresponding bytes using their percent-encoded form as defined in the URI and IRI specification. [RFC3986] [RFC3987] Applications/protocols that use this URI scheme name. Web Socket protocol. Interoperability considerations. None. Hickson Expires April 26, 2010 [Page 28]

Internet-Draft The Web Socket protocol October 2009 Security considerations. See "Security considerations" section above. Contact. Ian Hickson <ian@hixie.ch> Author/Change controller. Ian Hickson <ian@hixie.ch> References. This document. 8.2 . Registration of wss: scheme RFC5234] [RFC3986] "wss" ":" hier-part [ "?" query ] The path and query components form the resource name sent to the server to identify the kind of service desired. Other components have the meanings described in RFC3986. URI scheme semantics. The only operation for this scheme is to open a connection using the Web Socket protocol, encrypted using TLS. Encoding considerations. Characters in the host component that are excluded by the syntax defined above must be converted from Unicode to ASCII by applying the IDNA ToASCII algorithm to the Unicode host name, with both the AllowUnassigned and UseSTD3ASCIIRules flags set, and using the result of this algorithm as the host in the URI. [RFC3490] Characters in other components that are excluded by the syntax defined above must be converted from Unicode to ASCII by first encoding the characters as UTF-8 and then replacing the corresponding bytes using their percent-encoded form as defined in Hickson Expires April 26, 2010 [Page 29]

Internet-Draft The Web Socket protocol October 2009 the URI and IRI specification. [RFC3986] [RFC3987] Applications/protocols that use this URI scheme name. Web Socket protocol over TLS. Interoperability considerations. None. Security considerations. See "Security considerations" section above. Contact. Ian Hickson <ian@hixie.ch> Author/Change controller. Ian Hickson <ian@hixie.ch> References. This document. 8.3 . Registration of the "WebSocket" HTTP Upgrade keyword 8.4 . WebSocket-Origin RFC3864] Header field name WebSocket-Origin Applicable protocol http Hickson Expires April 26, 2010 [Page 30]

Internet-Draft The Web Socket protocol October 2009 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 |WebSocket-Origin| header is used in the WebSocket handshake. 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 verify that the server is willing to serve the script that opened the connection. 8.5 . WebSocket-Protocol RFC3864] Header field name WebSocket-Protocol 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 |WebSocket-Protocol| header is used in the WebSocket handshake. It is sent from the client to the server and back from the server to the client to confirm the subprotocol of the connection. This enables scripts to both select a subprotocol and be sure that the server agreed to serve that subprotocol. Hickson Expires April 26, 2010 [Page 31]

Internet-Draft The Web Socket protocol October 2009 8.6 . WebSocket-Location RFC3864] Header field name WebSocket-Location 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 |WebSocket-Location| header is used in the WebSocket handshake. It is sent from the server to the client to confirm the URL of the connection. This enables the client to verify that the connection was established to the right server, port, and path, instead of relying on the server to verify that the requested host, port, and path are correct. For example, consider a server running on port 20000 of a shared virtual host, on behalf of the author of www.example.com, which is hosted on that server. The author of the site hostile.example.net, also hosted on the same server, could write a script to connect to port 20000 on hostile.example.net; if neither the client nor the server verified that all was well, this would connect, and the author of the site hostile.example.net could then use the resources of www.example.com. With WebSocket, though, the server responds with a |WebSocket- Location| header in the handshake, explicitly saying that it is serving |ws://www.example.com:20000/|. The client, expecting (in the case of its use by the hostile author) that the |WebSocket- Location| be |ws://hostile.example.net:20000/|, would abort the connection. Hickson Expires April 26, 2010 [Page 32]

Internet-Draft The Web Socket protocol October 2009 9 . Using the Web Socket protocol from other specifications ORIGIN] o Optionally a string identifying a protocol that is to be layered over the Web Socket connection. The /host/, /port/, /resource name/, and /secure/ flag are usually obtained from a URL using the steps to parse a Web Socket URL's components. These steps fail if the URL does not specify a Web Socket. If a connection can be established, then it is said that the "Web Socket connection is established". If at any time the connection is to be closed, then the specification needs to use the "close the Web Socket connection" algorithm. When the connection is closed, for any reason including failure to establish the connection in the first place, it is said that the "Web Socket connection is closed". While a connection is open, the specification will need to handle the cases when "a Web Socket message has been received" with text /data/. To send some text /data/ to an open connection, the specification needs to "send /data/ using the Web Socket". Hickson Expires April 26, 2010 [Page 33]

Internet-Draft The Web Socket protocol October 2009 [WSAPI] Hickson, I., "The Web Sockets API", October 2009. Hickson Expires April 26, 2010 [Page 35]

Internet-Draft The Web Socket protocol October 2009 Author's Address Ian Hickson Google, Inc. Email: ian@hixie.ch URI: http://ln.hixie.ch/ Hickson Expires April 26, 2010 [Page 36]