--- 1/draft-ietf-hybi-thewebsocketprotocol-05.txt 2011-02-26 01:17:13.000000000 +0100 +++ 2/draft-ietf-hybi-thewebsocketprotocol-06.txt 2011-02-26 01:17:13.000000000 +0100 @@ -1,18 +1,18 @@ HyBi Working Group I. Fette Internet-Draft Google, Inc. -Intended status: Standards Track February 8, 2011 -Expires: August 12, 2011 +Intended status: Standards Track February 25, 2011 +Expires: August 29, 2011 The WebSocket protocol - draft-ietf-hybi-thewebsocketprotocol-05 + draft-ietf-hybi-thewebsocketprotocol-06 Abstract The WebSocket 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 security model used for this is the Origin-based security model commonly used by Web browsers. 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 @@ -30,21 +30,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on August 12, 2011. + This Internet-Draft will expire on August 29, 2011. Copyright Notice Copyright (c) 2011 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -61,68 +61,78 @@ 1.2. Protocol overview . . . . . . . . . . . . . . . . . . . . 4 1.3. Opening handshake . . . . . . . . . . . . . . . . . . . . 6 1.4. Closing handshake . . . . . . . . . . . . . . . . . . . . 8 1.5. Design philosophy . . . . . . . . . . . . . . . . . . . . 9 1.6. Security model . . . . . . . . . . . . . . . . . . . . . . 9 1.7. Relationship to TCP and HTTP . . . . . . . . . . . . . . . 10 1.8. Establishing a connection . . . . . . . . . . . . . . . . 10 1.9. Subprotocols using the WebSocket protocol . . . . . . . . 11 2. Conformance requirements . . . . . . . . . . . . . . . . . . . 12 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 12 - 3. WebSocket URLs . . . . . . . . . . . . . . . . . . . . . . . . 14 - 3.1. Parsing WebSocket URLs . . . . . . . . . . . . . . . . . . 14 - 3.2. Constructing WebSocket URLs . . . . . . . . . . . . . . . 15 - 3.3. Valid WebSocket URLs . . . . . . . . . . . . . . . . . . . 15 + 3. WebSocket URIs . . . . . . . . . . . . . . . . . . . . . . . . 14 + 3.1. Parsing WebSocket URIs . . . . . . . . . . . . . . . . . . 14 + 3.2. Constructing WebSocket URIs . . . . . . . . . . . . . . . 15 + 3.3. Valid WebSocket URIs . . . . . . . . . . . . . . . . . . . 15 4. Data Framing . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2. Client-to-Server Masking . . . . . . . . . . . . . . . . . 16 4.3. Base Framing Protocol . . . . . . . . . . . . . . . . . . 17 4.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 19 - 4.5. Control Frames . . . . . . . . . . . . . . . . . . . . . . 20 - 4.5.1. Close . . . . . . . . . . . . . . . . . . . . . . . . 20 + 4.5. Control Frames . . . . . . . . . . . . . . . . . . . . . . 21 + 4.5.1. Close . . . . . . . . . . . . . . . . . . . . . . . . 21 4.5.2. Ping . . . . . . . . . . . . . . . . . . . . . . . . . 21 - 4.5.3. Pong . . . . . . . . . . . . . . . . . . . . . . . . . 21 - 4.6. Data Frames . . . . . . . . . . . . . . . . . . . . . . . 21 + 4.5.3. Pong . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 4.6. Data Frames . . . . . . . . . . . . . . . . . . . . . . . 22 4.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 22 - 4.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 22 + 4.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 23 5. Opening Handshake . . . . . . . . . . . . . . . . . . . . . . 24 5.1. Client Requirements . . . . . . . . . . . . . . . . . . . 24 5.2. Server-side requirements . . . . . . . . . . . . . . . . . 28 5.2.1. Reading the client's opening handshake . . . . . . . . 29 5.2.2. Sending the server's opening handshake . . . . . . . . 29 - 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 33 - 6.1. Handling errors in UTF-8 from the server . . . . . . . . . 33 - 6.2. Handling errors in UTF-8 from the client . . . . . . . . . 33 - 7. Closing the connection . . . . . . . . . . . . . . . . . . . . 34 - 7.1. Abnormal closures . . . . . . . . . . . . . . . . . . . . 34 - 7.1.1. Client-initiated closure . . . . . . . . . . . . . . . 34 - 7.1.2. Server-initiated closure . . . . . . . . . . . . . . . 34 - 7.2. Normal closure of connections . . . . . . . . . . . . . . 34 - 8. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 36 - 8.1. Negotiating extensions . . . . . . . . . . . . . . . . . . 36 - 8.2. Known extensions . . . . . . . . . . . . . . . . . . . . . 37 - 8.2.1. Compression . . . . . . . . . . . . . . . . . . . . . 37 - 9. Security considerations . . . . . . . . . . . . . . . . . . . 39 - 10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 40 - 10.1. Registration of ws: scheme . . . . . . . . . . . . . . . . 40 - 10.2. Registration of wss: scheme . . . . . . . . . . . . . . . 41 - 10.3. Registration of the "WebSocket" HTTP Upgrade keyword . . . 42 - 10.4. Sec-WebSocket-Key and Sec-WebSocket-Nonce . . . . . . . . 42 - 10.5. Sec-WebSocket-Extensions . . . . . . . . . . . . . . . . . 43 - 10.6. Sec-WebSocket-Accept . . . . . . . . . . . . . . . . . . . 44 - 10.7. Sec-WebSocket-Origin . . . . . . . . . . . . . . . . . . . 45 - 10.8. Sec-WebSocket-Protocol . . . . . . . . . . . . . . . . . . 45 - 10.9. Sec-WebSocket-Version . . . . . . . . . . . . . . . . . . 46 - 11. Using the WebSocket protocol from other specifications . . . . 47 - 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 48 - 13. Normative References . . . . . . . . . . . . . . . . . . . . . 49 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 51 + 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 32 + 6.1. Handling errors in UTF-8 from the server . . . . . . . . . 32 + 6.2. Handling errors in UTF-8 from the client . . . . . . . . . 32 + 7. Closing the connection . . . . . . . . . . . . . . . . . . . . 33 + 7.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 33 + 7.1.1. Close the WebSocket Connection . . . . . . . . . . . . 33 + 7.1.2. Start the WebSocket Closing Handshake . . . . . . . . 33 + 7.1.3. The WebSocket Connection Is Closed . . . . . . . . . . 33 + 7.1.4. Fail the WebSocket Connection . . . . . . . . . . . . 33 + 7.2. Abnormal closures . . . . . . . . . . . . . . . . . . . . 34 + 7.2.1. Client-initiated closure . . . . . . . . . . . . . . . 34 + 7.2.2. Server-initiated closure . . . . . . . . . . . . . . . 34 + 7.3. Normal closure of connections . . . . . . . . . . . . . . 34 + 7.4. Status codes . . . . . . . . . . . . . . . . . . . . . . . 34 + 7.4.1. Defined Status Codes . . . . . . . . . . . . . . . . . 34 + 7.4.2. Reserved status code ranges . . . . . . . . . . . . . 35 + 8. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 37 + 8.1. Negotiating extensions . . . . . . . . . . . . . . . . . . 37 + 8.2. Known extensions . . . . . . . . . . . . . . . . . . . . . 38 + 8.2.1. Compression . . . . . . . . . . . . . . . . . . . . . 38 + 9. Security considerations . . . . . . . . . . . . . . . . . . . 40 + 10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 42 + 10.1. Registration of ws: scheme . . . . . . . . . . . . . . . . 42 + 10.2. Registration of wss: scheme . . . . . . . . . . . . . . . 43 + 10.3. Registration of the "WebSocket" HTTP Upgrade keyword . . . 44 + 10.4. Sec-WebSocket-Key . . . . . . . . . . . . . . . . . . . . 44 + 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.1. Background _This section is non-normative._ Historically, creating an instant messenger chat client as a Web application has required an abuse of HTTP to poll the server for updates while sending upstream notifications as distinct HTTP calls. @@ -158,29 +168,28 @@ The handshake from the client looks as follows: GET /chat HTTP/1.1 Host: server.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Sec-WebSocket-Origin: http://example.com Sec-WebSocket-Protocol: chat, superchat - Sec-WebSocket-Version: 5 + Sec-WebSocket-Version: 6 The handshake from the server looks as follows: HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= - Sec-WebSocket-Nonce: AQIDBAUGBwgJCgsMDQ4PEC== Sec-WebSocket-Protocol: chat The leading line from the client follows the Request-Line format. The leading line from the server follows the Status-Line format. The Request-Line and Status-Line productions are defined in [RFC2616]. After the leading line in both cases come an unordered set of headers. The meaning of these headers is specified in Section 5 of this document. Additional headers may also be present, such as cookies required to identify the user. The format and parsing of @@ -226,21 +235,21 @@ clients talking to that server. To this end, the WebSocket client's handshake is an HTTP Upgrade request: GET /chat HTTP/1.1 Host: server.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Sec-WebSocket-Origin: http://example.com 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; the order is not meaningful. Additional headers are used to select options in the WebSocket protocol. Options available in this version are the subprotocol selector, |Sec-WebSocket-Protocol|, and |Cookie|, which can used for sending cookies to the server (e.g. as an authentication mechanism). The |Sec-WebSocket-Protocol| request-header field can be used to indicate what subprotocols (application-level protocols layered over @@ -298,22 +307,24 @@ then base64-encoded, to give the value "s3pPLMBiTxaQ9kYGzzhZRbK+ xOo=". This value would then be echoed in the header |Sec-WebSocket- Accept|. The handshake from the server is much simpler than the client handshake. The first line is an HTTP Status-Line, with the status code 101: HTTP/1.1 101 Switching Protocols - Any status code other than 101 must be treated as a failure and the - websocket connection aborted. The headers follow the status code. + Any status code other than 101 MUST be treated as a failure if + 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 |Sec-WebSocket-Accept| header indicates whether the server is willing to accept the connection. If present, this header must include a hash of the client's nonce sent in |Sec-WebSocket-Key| along with a predefined GUID. Any other value must not be interpreted as an acceptance of the connection by the server. HTTP/1.1 101 Switching Protocols Upgrade: websocket @@ -339,38 +350,41 @@ The server can also set cookie-related option fields to _set_ cookies, as in HTTP. 1.4. Closing handshake _This section is non-normative._ The closing handshake is far simpler than the opening handshake. Either peer can send a control frame with data containing a specified - control sequence to begin the closing handshake. Upon receiving such - a frame, the other peer sends an identical frame in acknowledgement, - if it hasn't already sent one. Upon receiving _that_ control frame, - the first peer then closes the connection, safe in the knowledge that - no further data is forthcoming. + control sequence to begin the closing handshake (detailed in + Section 4.5.1). Upon receiving such a frame, the other peer sends a + close frame in response, if it hasn't already sent one. Upon + receiving _that_ control frame, the first peer then closes the + connection, safe in the knowledge that no further data is + forthcoming. After sending a control frame indicating the connection should be closed, a peer does not send any further data; after receiving a control frame indicating the connection should be closed, a peer discards any further data received. It is safe for both peers to initiate this handshake simultaneously. The closing handshake is intended to replace the TCP closing 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- the-middle proxies and other intermediaries. + By sending a close frame and waiting for a close frame in response, + 1.5. Design philosophy _This section is non-normative._ The WebSocket protocol is designed on the principle that there should be minimal framing (the only framing that exists is to make the protocol frame-based instead of stream-based, and to support a distinction between Unicode text and binary frames). It is expected 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 @@ -383,22 +397,21 @@ 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- implements the closing handshake in-band. Other than that, it adds 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 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 handshake also. The protocol is intended to be extensible; future versions will - likely introduce additional concepts such as multiplexing and - compression. + likely introduce additional concepts such as multiplexing. 1.6. Security model _This section is non-normative._ The WebSocket protocol uses the origin model used by Web browsers to 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 by a dedicated client directly (i.e. not from a Web page through a Web browser), the origin model is not @@ -411,69 +424,62 @@ limiting the data that can be inserted into the connection before the handshake is finished (thus limiting how much the server can be influenced). It is similarly intended to fail to establish a connection when data from other protocols, especially HTTP, is sent to a WebSocket server, for example as might happen if an HTML |form| were submitted to a WebSocket server. This is primarily achieved by requiring that 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 - sent by a WebSocket handshake; in particular, fields starting with - |Sec-| cannot be set by an attacker from a Web browser, even when - using |XMLHttpRequest|. + sent by a WebSocket handshake. In particular, at the time of writing + of this specification, fields starting with |Sec-| cannot be set by + an attacker from a Web browser using only HTML and JavaScript APIs + such as |XMLHttpRequest|. 1.7. Relationship to TCP and HTTP _This section is non-normative._ The WebSocket protocol is an independent TCP-based protocol. Its only relationship to HTTP is that its handshake is interpreted by HTTP servers as an Upgrade request. Based on the expert recommendation of the IANA, the WebSocket protocol by default uses port 80 for regular WebSocket connections and port 443 for WebSocket connections tunneled over TLS. 1.8. Establishing a connection _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 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 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 to a single hostname, this might allow a practical way for systems based on the WebSocket protocol to be deployed. In more elaborate setups (e.g. with load balancers and multiple servers), a dedicated 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 _This section is non-normative._ 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 the selected subprotocol values in its response for the connection to be established. These subprotocol names do not need to be registered, but if a subprotocol is intended to be implemented by multiple independent WebSocket servers, potential clashes with the names of subprotocols defined independently can be avoided by using names that contain the domain name of the subprotocol's originator. For example, if Example Corporation were to create a Chat subprotocol to be implemented by @@ -534,119 +540,120 @@ range U+0061 to U+007A (i.e. LATIN SMALL LETTER A to LATIN SMALL LETTER Z). Comparing two strings in an *ASCII case-insensitive* manner means 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 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 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 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 WebSocket protocol, the implementation may delay the actual transmission arbitrarily, e.g. buffering data so as to send fewer IP 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 /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] - 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 - URL character encoding set to UTF-8. [RFC3629] [RFC3986] + URI character encoding set to UTF-8. [RFC3629] [RFC3986] [RFC3987] 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 component whose value, when + 3. If /uri/ does not have a component whose value, when converted to ASCII lowercase, is either "ws" or "wss", then fail this algorithm. - 4. If /url/ has a component, then fail this algorithm. + 4. If /uri/ has a component, then fail this algorithm. - 5. If the component of /url/ is "ws", set /secure/ to - false; otherwise, the component is "wss", set /secure/ - to true. + 5. If the component of /uri/ is "ws", set /secure/ to + false; otherwise, if the component is "wss", set + /secure/ to true; otherwise, fail this algorithm. - 6. Let /host/ be the value of the component of /url/, + 6. Let /host/ be the value of the component of /uri/, converted to ASCII lowercase. - 7. If /url/ has a component, then let /port/ be that + 7. If /uri/ has a 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 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 character U+002F SOLIDUS (/). - 11. If /url/ has a component, then append a single U+003F + 11. If /uri/ has a component, then append a single U+003F QUESTION MARK character (?) to /resource name/, followed by the value of the component. 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: - 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 - /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 /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. o The /host/ must be ASCII-only (i.e. it must have been punycode- encoded already if necessary, and MUST NOT contain any characters above U+007E). 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 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 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) 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 considered valid by the criteria above. 4. Data Framing 4.1. Overview In the WebSocket protocol, data is transmitted using a sequence of frames. Frames sent from the client to the server are masked to avoid confusing network intermediaries, such as intercepting proxies. @@ -654,22 +661,22 @@ The base framing protocol defines a frame type with an opcode, a payload length, and designated locations for extension and application data, which together define the _payload_ data. Certain bits and opcodes are reserved for future expansion of the protocol. As such, In the absence of extensions negotiated during the opening handshake (Section 5), all reserved bits MUST be 0 and reserved opcode values MUST NOT be used. A data frame MAY be transmitted by either the client or the server at - any time after handshake completion and before that host has - generated a close message (Section 4.5.1). + any time after handshake completion and before that endpoint has sent + a close message (Section 4.5.1). 4.2. Client-to-Server Masking The client MUST mask all frames sent to the server. 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 MUST be derived from a strong source of entropy, and the masking-key for a given frame MUST NOT make it simple for a @@ -802,89 +809,112 @@ frame-length-16 = %x0000-FFFF frame-length-63 = %x0000000000000000-7FFFFFFFFFFFFFFF frame-extension = *( %x00-FF ) ; to be defined later application-data = *( %x00-FF ) 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: o An unfragmented message consists of a single frame with the FIN bit set and an opcode other than 0. 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 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 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 - interjected in the middle of a fragmented message. If so, it must - be decided whether they be fragmented (which would require keeping - a stack of "in-progress" messages)._ + o Control frames MAY be injected in the middle of a fragmented + message. Control frames themselves MUST NOT be fragmented. _Note: + if control frames could not be interjected, the latency of a ping, + 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 messages. o Clients and servers MUST support receiving both fragmented and unfragmented messages. o An intermediary MAY change the fragmentation of a message if the message uses only opcode and reserved bit values known to the 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 Control frames have opcodes of 0x01 (Close), 0x02 (Ping), or 0x03 (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 be fragmented. 4.5.1. Close The Close message contains an opcode of 0x01. - The Close message contains a body that is at least one byte in - length. If the close is initiated by the client, the first byte of - the body MUST be a 0x43. If the close is initiated by the server, - the first byte of the body MUST be a 0x53. The body MAY contain - additional bytes, the meaning of those bytes are not defined by this - version of the protocol. + The Close message MAY contain a body (the "application data" portion + of the frame) that indicates a reason for closing, such as an + endpoint shutting down, an endpoint having received a message too + large, or an endpoint having received a message that does not conform + to the format expected by the other endpoint. If there is a body, + 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 close message. - A received close message is deemed to be an acknowledgement if the - message body matches the body of a close message previously sent by - the receiver. - - 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. + If an endpoint receives a Close message and that endpoint did not + previously send a Close message, the endpoint MUST send a Close + message in response. It SHOULD do so as soon as is practical. - The websocket is considered fully closed when an endpoint has either - received a close acknowledgment or sent a close acknowledgment. + After both sending and receiving a close message, an endpoint + considers the websocket connection closed, and SHOULD close the + underlying TCP connection. - To prevent a situation where ambiguity arises from a client and - server both sending a close frame at approximately the same time, the - close frame has a body that can be used to distinguish whether a - close frame is an initiation of a close event or the acknowledgement - of the other side's close. (Without resolving the ambiguity, a party - has no way of knowing whether its last bytes before the close frame - were received). + If a client and server both send a Close message at the same time, + both endpoints will have sent and received a Close message and should + consider the websocket connection closed and close the underlying TCP + connection. 4.5.2. Ping The Ping message contains an opcode of 0x02. 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 bodies of the Ping and Pong MUST be the same. 4.5.3. Pong @@ -971,32 +1001,33 @@ 5.1. Client Requirements User agents running in controlled environments, e.g. browsers on mobile handsets tied to specific carriers, may offload the management of the connection to another agent on the network. In such a situation, the user agent for the purposes of conformance is considered to include both the handset software and any such agents. 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 "/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 MUST fail the WebSocket connection and abort these steps. 2. If the user agent already has a WebSocket connection to the remote host (IP address) identified by /host/, even if known by 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 simultaneously, the user agent MUST serialize them so that there is no more than one connection at a time running through the following steps. If the user agent cannot determine the IP address of the remote host (for example because all communication is being done through a proxy server that performs DNS queries itself), then the user agent MUST assume for the purposes of this step that each host name refers to a distinct remote host, but should instead limit @@ -1041,24 +1072,24 @@ TCP connection SHOULD be opened 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 WebSocket connections separate from other proxies are encouraged to use a SOCKS proxy for WebSocket 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 + For the purpose of proxy autoconfiguration scripts, the URI to pass the function must be constructed from /host/, /port/, /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 autoconfiguration scripts from the scheme ("ws:" for unencrypted connections and "wss:" for encrypted connections). 4. If the connection could not be opened, either because a direct connection failed or because any proxy used returned an error, then the user agent MUST fail the WebSocket connection and abort the connection attempt. @@ -1077,34 +1108,34 @@ MUST send a handshake to the server. The handshake consists of an HTTP upgrade request, along with a list of required and optional headers. The requirements for this handshake are as follows. 1. The handshake must be a valid HTTP request as specified by [RFC2616]. 2. The Method of the request MUST be GET and the HTTP version MUST 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" 3. The request must contain a "Request-URI" as part of the GET method. This MUST match the /resource name/ Section 3. 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 equal to "websocket". - 6. The request MUST contain a "Connection" header whose value is - equal to "Upgrade". + 6. The request MUST contain a "Connection" header whose value MUST + include the "Upgrade" token. 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 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 @@ -1119,36 +1150,35 @@ which the code establishing the connection is running, and MUST be lower-case. The value MUST NOT contain letters in the range U+0041 to U+005A (i.e. LATIN CAPITAL LETTER A to LATIN CAPITAL LETTER Z) [I-D.ietf-websec-origin]. As an example, if code is running on www.example.com attempting to establish a connection to ww2.example.com, the value of the header would be "http://www.example.com". 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- Protocol". If present, this value indicates the subprotocol(s) the client wishes to speak. The elements that comprise this 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 of this header is 1#(token | quoted-string), where the definitions of constructs and rules are as given in [RFC2616]. 11. The request MAY include a header with the name "Sec-WebSocket- Extensions". If present, this value indicates the protocol- - level extension(s) the client wishes to speak. The ABNF for the - value of this header is 1#(token | quoted-string), where the - definitions of constructs and rules are as given in [RFC2616]. - The interpretation of this header is described in Section 8.1. + level extension(s) the client wishes to speak. The + interpretation and format of this header is described in + Section 8.1. 12. The request MAY include headers associated with sending cookies, as defined by the appropriate specifications [I-D.ietf-httpstate-cookie]. Once the client's opening handshake has been sent, the client MUST wait for a response from the server before sending any further data. The client MUST validate the server's response as follows: o If the status code received from the server is not 101, the client @@ -1220,23 +1250,25 @@ 1. An HTTP/1.1 or higher GET request, including a "Request-URI" [RFC2616] that should be interpreted as a /resource name/ Section 3. 2. A "Host" header containing the server's authority. 3. A "Sec-WebSocket-Key" header with a base64-encoded value that, 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 values indicating which protocols the client would like to speak, ordered by preference. 7. Optionally, a "Sec-WebSocket-Extensions" header, with a list of values indicating which extensions the client would like to speak. The interpretation of this header is discussed in Section 8.1. @@ -1329,34 +1361,24 @@ "dGhlIHNhbXBsZSBub25jZQ==", the server would append the string "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" to form the string "dGhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CA- C5AB0DC85B11". The server would then take the SHA-1 hash of this string, giving the value 0xb3 0x7a 0x4f 0x2c 0xc0 0x62 0x4f 0x16 0x90 0xf6 0x46 0x06 0xcf 0x38 0x59 0x45 0xb2 0xbe 0xc4 0xea. This value is then base64-encoded, to give the value "s3pPLMBiTxaQ9kYGzzhZRbK+xOo=", which would be returned in the "Sec-WebSocket-Accept" header. - 3. A "Sec-WebSocket-Nonce" header. The value of this header - 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 + 3. Optionally, a "Sec-WebSocket-Protocol" header, with a value /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. This completes the server's handshake. If the server finishes these steps without aborting the WebSocket connection, and if the client does not then fail the WebSocket connection, then the connection is established and the server may begin sending and receiving data, as described in the next section. 6. Error Handling @@ -1371,76 +1393,163 @@ 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 undefined. A server could close the connection, convert invalid byte sequences to U+FFFD REPLACEMENT CHARACTERs, store the data verbatim, or perform application-specific processing. Subprotocols layered on the WebSocket protocol might define specific behavior for servers. 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 - 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). + To _Close the WebSocket Connection_, an endpoint closes the + underlying TCP connection. An endpoint SHOULD use a method that + cleanly closes the TCP connection, discarding any trailing bytes that + 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 (e.g. a script using the WebSocket API), user agents should not close the connection. - User agents must not convey any failure information to scripts in a - way that would allow a script to distinguish the following - situations: +7.2.2. Server-initiated closure - 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 - it was not a WebSocket server). +7.4. Status codes - o A WebSocket server that sent a correct opening handshake, but that - specified options that caused the client to drop the connection - (e.g. the server specified an origin that differed from the - script's). + When closing an established connection (e.g. when sending a Close + frame, after the handshake has completed), an endpoint MAY indicate a + reason for closure. The interpretation of this reason by an + 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 - successfully completing the opening handshake. +7.4.1. Defined Status Codes -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 - WebSocket connection* during the opening handshake. To do so, the - server must simply close the WebSocket connection. + 1000 -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 - 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_. + 1001 - Servers may close the WebSocket connection whenever desired. User - agents should not close the WebSocket connection arbitrarily. + 1001 indicates that an endpoint is "going away", such as a server + 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 WebSocket clients MAY request extensions to this specification, and WebSocket servers MAY accept some or all extensions requested by the client. A server MUST NOT respond with any extension not requested by the client. If extension parameters are included in negotiations between the client and the server, those parameters MUST be chosen in accordance with the specification of the extension to which the parameters apply. @@ -1562,25 +1671,41 @@ does not correspond to the values the server is expecting (e.g. incorrect path or origin), the server should just disconnect. It is always safe to disconnect. The biggest security risk when sending text data using this protocol is sending data using the wrong encoding. If an attacker can trick the server into sending data encoded as ISO-8859-1 verbatim (for instance), rather than encoded as UTF-8, then the attacker could 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.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. ws Status. Permanent. URI scheme syntax. In ABNF terms using the terminals from the URI specifications: [RFC5234] [RFC3986] @@ -1621,21 +1746,21 @@ Ian Hickson Author/Change controller. Ian Hickson References. This document. 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. URI scheme name. wss Status. Permanent. URI scheme syntax. In ABNF terms using the terminals from the URI specifications: @@ -1689,68 +1814,49 @@ Author/Change controller. Ian Hickson Contact. Ian Hickson References. 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] Header field name Sec-WebSocket-Key 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. - Header field name - Sec-WebSocket-Nonce - - Applicable protocol - http - - Status - reserved; do not use outside WebSocket handshake - - Author/Change controller - IETF - - Specification document(s) - This document is the relevant specification. - - Related information - None. - - The |Sec-WebSocket-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. + The |Sec-WebSocket-Key| header is used in the WebSocket handshake. + It is sent from the client to the server to provide part of the + information used by the server to prove that it received a valid + WebSocket handshake. This helps ensure that the server does not + accept connections from non-WebSocket clients (e.g. HTTP clients) + that are being abused to send data to unsuspecting WebSocket servers. 10.5. Sec-WebSocket-Extensions This section describes a header field for registration in the Permanent Message Header Field Registry. [RFC3864] Header field name Sec-WebSocket-Extensions Applicable protocol @@ -1905,22 +2011,22 @@ o A /secure/ flag, which is true if the connection is to be encrypted, and false otherwise. o An ASCII serialization of an origin that is being made responsible for the connection. [I-D.ietf-websec-origin] o Optionally a string identifying a protocol that is to be layered over the WebSocket connection. The /host/, /port/, /resource name/, and /secure/ flag are usually - obtained from a URL using the steps to parse a WebSocket URL's - components. These steps fail if the URL does not specify a + obtained from a URI using the steps to parse a WebSocket URI's + components. These steps fail if the URI does not specify a WebSocket. If a connection can be established, then it is said that the "WebSocket connection is established". If at any time the connection is to be closed, then the specification needs to use the "close the WebSocket 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 @@ -1932,33 +2038,111 @@ To send some text /data/ to an open connection, the specification needs to "send /data/ using the WebSocket". 12. Acknowledgements Special thanks are due to Ian Hickson, who was the original author and editor of this protocol. The initial design of this specification benefitted from the participation of many people in the WHATWG and WHATWG mailing list. Contributions to that specification 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 amount of text for the Data Framing section of this specification. Special thanks also to Adam Barth for providing a significant amount of text and background research for the Data Masking section of this 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 + 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] American National Standards Institute, "Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986. [FIPS.180-2.2002] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-2, August 2002, .