[html5] r4814 - [giowt] (0) First draft of possible change to the WebSocket handshake. Also, mak [...]
whatwg at whatwg.org
whatwg at whatwg.org
Tue Mar 2 01:01:45 PST 2010
Author: ianh
Date: 2010-03-02 01:01:43 -0800 (Tue, 02 Mar 2010)
New Revision: 4814
Modified:
complete.html
index
source
Log:
[giowt] (0) First draft of possible change to the WebSocket handshake. Also, make the protocol and API be consistently called WebSocket.
Modified: complete.html
===================================================================
--- complete.html 2010-02-25 10:55:53 UTC (rev 4813)
+++ complete.html 2010-03-02 09:01:43 UTC (rev 4814)
@@ -157,7 +157,7 @@
<header class=head id=head><p><a class=logo href=http://www.whatwg.org/ rel=home><img alt=WHATWG src=/images/logo></a></p>
<hgroup><h1>Web Applications 1.0</h1>
- <h2 class="no-num no-toc">Draft Standard — 25 February 2010</h2>
+ <h2 class="no-num no-toc">Draft Standard — 2 March 2010</h2>
</hgroup><p>You can take part in this work. <a href=http://www.whatwg.org/mailing-list>Join the working group's discussion list.</a></p>
<p><strong>Web designers!</strong> We have a <a href=http://blog.whatwg.org/faq/>FAQ</a>, a <a href=http://forums.whatwg.org/>forum</a>, and a <a href=http://www.whatwg.org/mailing-list#help>help mailing list</a> for you!</p>
<!--<p class="impl"><strong>Implementors!</strong> We have a <a href="http://www.whatwg.org/mailing-list#implementors">mailing list</a> for you too!</p>-->
@@ -946,7 +946,7 @@
<li><a href=#feedback-from-the-protocol><span class=secno>10.3.3 </span>Feedback from the protocol</a>
<ol>
<li><a href=#garbage-collection-1><span class=secno>10.3.3.1 </span>Garbage collection</a></ol></li>
- <li><a href=#websocket-protocol title="The Web Socket protocol enables
+ <li><a href=#websocket-protocol title="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
@@ -956,46 +956,48 @@
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)."><span class=secno>10.3.4 </span>The Web Socket protocol</a>
+ <iframe>s and long polling)."><span class=secno>10.3.4 </span>The WebSocket protocol</a>
<ol>
<li><a href=#introduction-7><span class=secno>10.3.4.1 </span>Introduction</a>
<ol>
<li><a href=#background-0><span class=secno>10.3.4.1.1 </span>Background</a></li>
<li><a href=#protocol-overview><span class=secno>10.3.4.1.2 </span>Protocol overview</a></li>
- <li><a href=#design-philosophy><span class=secno>10.3.4.1.3 </span>Design philosophy</a></li>
- <li><a href=#security-model><span class=secno>10.3.4.1.4 </span>Security model</a></li>
- <li><a href=#relationship-to-tcp/ip-and-http><span class=secno>10.3.4.1.5 </span>Relationship to TCP/IP and HTTP</a></li>
- <li><a href=#establishing-a-connection><span class=secno>10.3.4.1.6 </span>Establishing a connection</a></li>
- <li><a href=#writing-a-simple-web-socket-server><span class=secno>10.3.4.1.7 </span>Writing a simple Web Socket server</a></li>
- <li><a href=#subprotocols-using-the-web-socket-protocol><span class=secno>10.3.4.1.8 </span>Subprotocols using the Web Socket protocol</a></li>
+ <li><a href=#handshake><span class=secno>10.3.4.1.3 </span>Handshake</a></li>
+ <li><a href=#design-philosophy><span class=secno>10.3.4.1.4 </span>Design philosophy</a></li>
+ <li><a href=#security-model><span class=secno>10.3.4.1.5 </span>Security model</a></li>
+ <li><a href=#relationship-to-tcp-and-http><span class=secno>10.3.4.1.6 </span>Relationship to TCP and HTTP</a></li>
+ <li><a href=#establishing-a-connection><span class=secno>10.3.4.1.7 </span>Establishing a connection</a></li>
+ <li><a href=#subprotocols-using-the-websocket-protocol><span class=secno>10.3.4.1.8 </span>Subprotocols using the WebSocket protocol</a></li>
<li><a href=#terminology-1><span class=secno>10.3.4.1.9 </span>Terminology</a></ol></li>
- <li><a href=#web-socket-urls><span class=secno>10.3.4.2 </span>Web Socket URLs</a>
+ <li><a href=#websocket-urls><span class=secno>10.3.4.2 </span>WebSocket URLs</a>
<ol>
- <li><a href=#parsing-web-socket-urls><span class=secno>10.3.4.2.1 </span>Parsing Web Socket URLs</a></li>
- <li><a href=#constructing-web-socket-urls><span class=secno>10.3.4.2.2 </span>Constructing Web Socket URLs</a></ol></li>
+ <li><a href=#parsing-websocket-urls><span class=secno>10.3.4.2.1 </span>Parsing WebSocket URLs</a></li>
+ <li><a href=#constructing-websocket-urls><span class=secno>10.3.4.2.2 </span>Constructing WebSocket URLs</a></ol></li>
<li><a href=#client-side-requirements><span class=secno>10.3.4.3 </span>Client-side requirements</a>
<ol>
- <li><a href=#handshake><span class=secno>10.3.4.3.1 </span>Handshake</a></li>
+ <li><a href=#handshake-0><span class=secno>10.3.4.3.1 </span>Handshake</a></li>
<li><a href=#data-framing><span class=secno>10.3.4.3.2 </span>Data framing</a></li>
- <li><a href=#closing-the-connection><span class=secno>10.3.4.3.3 </span>Closing the connection</a></li>
+ <li><a href=#failing-the-connection><span class=secno>10.3.4.3.3 </span>Failing the connection</a></li>
<li><a href=#handling-errors-in-utf-8><span class=secno>10.3.4.3.4 </span>Handling errors in UTF-8</a></ol></li>
<li><a href=#server-side-requirements><span class=secno>10.3.4.4 </span>Server-side requirements</a>
<ol>
- <li><a href="#sending-the-server's-handshake"><span class=secno>10.3.4.4.1 </span>Sending the server's handshake</a></li>
- <li><a href="#reading-the-client's-handshake"><span class=secno>10.3.4.4.2 </span>Reading the client's handshake</a></li>
+ <li><a href="#reading-the-client's-handshake"><span class=secno>10.3.4.4.1 </span>Reading the client's handshake</a></li>
+ <li><a href="#sending-the-server's-handshake"><span class=secno>10.3.4.4.2 </span>Sending the server's handshake</a></li>
<li><a href=#ws-sd-framing><span class=secno>10.3.4.4.3 </span>Data framing</a></li>
- <li><a href=#handling-errors-in-utf-8-0><span class=secno>10.3.4.4.4 </span>Handling errors in UTF-8</a></ol></li>
- <li><a href=#closing-the-connection-0><span class=secno>10.3.4.5 </span>Closing the connection</a></li>
+ <li><a href=#aborting-the-connection><span class=secno>10.3.4.4.4 </span>Aborting the connection</a></li>
+ <li><a href=#handling-errors-in-utf-8-0><span class=secno>10.3.4.4.5 </span>Handling errors in UTF-8</a></ol></li>
+ <li><a href=#closing-the-connection><span class=secno>10.3.4.5 </span>Closing the connection</a></li>
<li><a href=#security-considerations><span class=secno>10.3.4.6 </span>Security considerations</a></li>
<li><a href=#iana-considerations-0><span class=secno>10.3.4.7 </span>IANA considerations</a>
<ol>
<li><a href=#registration-of-ws:-scheme><span class=secno>10.3.4.7.1 </span>Registration of <code title="">ws:</code> scheme</a></li>
<li><a href=#registration-of-wss:-scheme><span class=secno>10.3.4.7.2 </span>Registration of <code title="">wss:</code> scheme</a></li>
<li><a href=#registration-of-the-websocket-http-upgrade-keyword><span class=secno>10.3.4.7.3 </span>Registration of the "<code title="">WebSocket</code>" HTTP Upgrade keyword</a></li>
- <li><a href=#websocket-origin><span class=secno>10.3.4.7.4 </span><code>WebSocket-Origin</code></a></li>
- <li><a href=#websocket-protocol-0><span class=secno>10.3.4.7.5 </span><code>WebSocket-Protocol</code></a></li>
- <li><a href=#websocket-location><span class=secno>10.3.4.7.6 </span><code>WebSocket-Location</code></a></ol></li>
- <li><a href=#using-the-web-socket-protocol-from-other-specifications><span class=secno>10.3.4.8 </span>Using the Web Socket protocol from other specifications</a></ol></ol></li>
+ <li><a href=#sec-websocket-key1-and-sec-websocket-key2><span class=secno>10.3.4.7.4 </span><code>Sec-WebSocket-Key1</code> and <code>Sec-WebSocket-Key2</code></a></li>
+ <li><a href=#sec-websocket-location><span class=secno>10.3.4.7.5 </span><code>Sec-WebSocket-Location</code></a></li>
+ <li><a href=#sec-websocket-origin><span class=secno>10.3.4.7.6 </span><code>Sec-WebSocket-Origin</code></a></li>
+ <li><a href=#sec-websocket-protocol><span class=secno>10.3.4.7.7 </span><code>Sec-WebSocket-Protocol</code></a></ol></li>
+ <li><a href=#using-the-websocket-protocol-from-other-specifications><span class=secno>10.3.4.8 </span>Using the WebSocket protocol from other specifications</a></ol></ol></li>
<li><a href=#crossDocumentMessages><span class=secno>10.4 </span>Cross-document messaging</a>
<ol>
<li><a href=#introduction-8><span class=secno>10.4.1 </span>Introduction</a></li>
@@ -38446,16 +38448,16 @@
character not followed by a U+000A LINE FEED (LF) character, and
every occurrence of a U+000A LINE FEED (LF) character not preceded
by a U+000D CARRIAGE RETURN (CR) character, by a two-character
- string consisting of a U+000D CARRIAGE RETURN - U+000A LINE FEED
+ string consisting of a U+000D CARRIAGE RETURN U+000A LINE FEED
(CRLF) character pair.</li>
<li><p>If the element's <code title=attr-textarea-wrap><a href=#attr-textarea-wrap>wrap</a></code> attribute is in the <a href=#attr-textarea-wrap-hard-state title=attr-textarea-wrap-hard-state>Hard</a> state, insert
- U+000D CARRIAGE RETURN - U+000A LINE FEED (CRLF) character pairs
+ U+000D CARRIAGE RETURN U+000A LINE FEED (CRLF) character pairs
into the string using a UA-defined algorithm so that each line has
no more than <a href=#attr-textarea-cols-value title=attr-textarea-cols-value>character
width</a> characters. For the purposes of this requirement,
lines are delimited by the start of the string, the end of the
- string, and U+000D CARRIAGE RETURN - U+000A LINE FEED (CRLF)
+ string, and U+000D CARRIAGE RETURN U+000A LINE FEED (CRLF)
character pairs.</li>
</ol></div>
@@ -55650,7 +55652,7 @@
<code><a href=#document>Document</a></code>'s <var title=concept-document-salvageable>salvageable</var> state to
false. <a href=#refsWEBSQL>[WEBSQL]</a> </li>
- <li><p><a href=#close-the-web-socket-connection>Close the Web Socket connection</a> of any
+ <li><p><a href=#close-the-websocket-connection>Close the WebSocket connection</a> of any
<code><a href=#websocket>WebSocket</a></code> objects that were created by the <code title=dom-WebSocket><a href=#dom-websocket>WebSocket()</a></code> constructor visible on the
<code><a href=#document>Document</a></code>'s <code><a href=#window>Window</a></code> object. If this
affected any <code><a href=#websocket>WebSocket</a></code> objects, the set
@@ -66956,7 +66958,7 @@
must run these steps:</p>
<ol><!-- beware, this is very similar to the steps for what happens
- during a redirect, in the protocol section --><li><p><a href="#parse-a-web-socket-url's-components">Parse a Web Socket URL's components</a> from the
+ during a redirect, in the protocol section --><li><p><a href="#parse-a-websocket-url's-components">Parse a WebSocket URL's components</a> from the
<var title="">url</var> argument, to obtain <var title="">host</var>, <var title="">port</var>, <var title="">resource name</var>, and <var title="">secure</var>. If
this fails, throw a <code><a href=#syntax_err>SYNTAX_ERR</a></code> exception and abort
these steps.</li>
@@ -66985,16 +66987,16 @@
<li>
- <p><a href=#establish-a-web-socket-connection>Establish a Web Socket connection</a> to a host <var title="">host</var>, on port <var title="">port</var> (if one was
+ <p><a href=#establish-a-websocket-connection>Establish a WebSocket connection</a> to a host <var title="">host</var>, on port <var title="">port</var> (if one was
specified), from <var title="">origin</var>, with the flag <var title="">secure</var>, with <var title="">resource name</var> as
the resource name, and with <var title="">protocol</var> as the
protocol (if it is present).</p>
- <p class=note>If the "<a href=#establish-a-web-socket-connection>establish a Web Socket
- connection</a>" algorithm fails, it triggers the "<a href=#fail-the-web-socket-connection>fail
- the Web Socket connection</a>" algorithm, which then invokes
- the "<a href=#close-the-web-socket-connection>close the Web Socket connection</a>" algorithm,
- which then establishes that the "<a href=#web-socket-connection-is-closed>Web Socket connection is
+ <p class=note>If the "<a href=#establish-a-websocket-connection>establish a WebSocket
+ connection</a>" algorithm fails, it triggers the "<a href=#fail-the-websocket-connection>fail
+ the WebSocket connection</a>" algorithm, which then invokes
+ the "<a href=#close-the-websocket-connection>close the WebSocket connection</a>" algorithm,
+ which then establishes that the "<a href=#websocket-connection-is-closed>WebSocket connection is
closed</a>", which fires the <code title=event-close>close</code> event <a href=#closeWebSocket>as described below</a>.</p>
</li>
@@ -67019,7 +67021,7 @@
<dt><dfn id=dom-websocket-open title=dom-WebSocket-OPEN><code>OPEN</code></dfn> (numeric value 1)</dt>
- <dd>The <a href=#web-socket-connection-is-established>Web Socket connection is established</a> and communication is possible.</dd>
+ <dd>The <a href=#websocket-connection-is-established>WebSocket connection is established</a> and communication is possible.</dd>
<dt><dfn id=dom-websocket-closed title=dom-WebSocket-CLOSED><code>CLOSED</code></dfn> (numeric value 2)</dt>
@@ -67034,17 +67036,17 @@
raise an <code><a href=#invalid_state_err>INVALID_STATE_ERR</a></code> exception. If the <var title="">data</var> argument has any unpaired surrogates, then it
must raise <code><a href=#syntax_err>SYNTAX_ERR</a></code>. If the connection is
established, and the string has no unpaired surrogates, then the
- user agent must <a href=#send-data-using-the-web-socket>send <var title="">data</var> using the Web
- Socket</a>. If the data cannot be sent, e.g. because it would
+ user agent must <a href=#send-data-using-the-websocket>send <var title="">data</var> using the
+ WebSocket</a>. If the data cannot be sent, e.g. because it would
need to be buffered but the buffer is full, the user agent must
- <a href=#close-the-web-socket-connection>close the Web Socket connection</a>. The method must then
+ <a href=#close-the-websocket-connection>close the WebSocket connection</a>. The method must then
return true if the connection is still established (and the data was
queued or sent successfully), or false if the connection is closed
(e.g. because the user agent just had a buffer overflow and failed
to send the data).</p>
<p>The <dfn id=dom-websocket-close title=dom-WebSocket-close><code>close()</code></dfn>
- method must <a href=#close-the-web-socket-connection>close the Web Socket connection</a> or
+ method must <a href=#close-the-websocket-connection>close the WebSocket connection</a> or
connection attempt, if any, and change the <code title=dom-WebSocket-readyState><a href=#dom-websocket-readystate>readyState</a></code> attribute's value
to <code title=dom-WebSocket-CLOSED><a href=#dom-websocket-closed>CLOSED</a></code> (2). If the
connection is already closed, it must do nothing.</p>
@@ -67094,13 +67096,13 @@
<tr><td><dfn id=handler-websocket-onclose title=handler-WebSocket-onclose><code>onclose</code></dfn> <td> <code title=event-close>close</code>
</table><h4 id=feedback-from-the-protocol><span class=secno>10.3.3 </span>Feedback from the protocol</h4>
- <p>When the <i><a href=#web-socket-connection-is-established>Web Socket connection is established</a></i>, the user
+ <p>When the <i><a href=#websocket-connection-is-established>WebSocket connection is established</a></i>, the user
agent must <a href=#queue-a-task>queue a task</a> to first change the <code title=dom-WebSocket-readyState><a href=#dom-websocket-readystate>readyState</a></code> attribute's value
to <code title=dom-WebSocket-OPEN><a href=#dom-websocket-open>OPEN</a></code> (1), and then
<a href=#fire-a-simple-event>fire a simple event</a> named <code title=event-open>open</code> at the <code><a href=#websocket>WebSocket</a></code>
object.</p>
- <p>When <i>a Web Socket message has been received</i> with text <var title="">data</var>, the user agent must create an event that uses
+ <p>When <i><a href=#a-websocket-message-has-been-received>a WebSocket message has been received</a></i> with text <var title="">data</var>, the user agent must create an event that uses
the <code><a href=#messageevent>MessageEvent</a></code> interface, with the event name <code title=event-message><a href=#event-message>message</a></code>, which does not bubble, is not
cancelable, has no default action, and whose <code title=dom-MessageEvent-data><a href=#dom-messageevent-data>data</a></code> attribute is set to <var title="">data</var>, and <a href=#queue-a-task>queue a task</a> to check to see
if the <code title=dom-WebSocket-readyState><a href=#dom-websocket-readystate>readyState</a></code>
@@ -67108,7 +67110,7 @@
(1), and if so, dispatch the event at the <code><a href=#websocket>WebSocket</a></code>
object.</p>
- <p id=closeWebSocket>When the <i><a href=#web-socket-connection-is-closed>Web Socket connection is
+ <p id=closeWebSocket>When the <i><a href=#websocket-connection-is-closed>WebSocket connection is
closed</a></i>, the user agent must <a href=#queue-a-task>queue a task</a> to first
change the <code title=dom-WebSocket-readyState><a href=#dom-websocket-readystate>readyState</a></code>
attribute's value to <code title=dom-WebSocket-CLOSED><a href=#dom-websocket-closed>CLOSED</a></code> (2), and then <a href=#fire-a-simple-event>fire
@@ -67119,7 +67121,7 @@
runs.)</p>
<p>The <a href=#task-source>task source</a> for all <a href=#concept-task title=concept-task>tasks</a> <a href=#queue-a-task title="queue a
- task">queued</a> in this section is the <dfn id=web-socket-task-source>Web Socket task
+ task">queued</a> in this section is the <dfn id=websocket-task-source>WebSocket task
source</dfn>.</p>
@@ -67130,15 +67132,14 @@
<code title=event-message><a href=#event-message>message</a></code> events.</p>
<p>If a <code><a href=#websocket>WebSocket</a></code> object is garbage collected while its
- connection is still open, the user agent must <a href=#close-the-web-socket-connection>close the Web
- Socket connection</a>.</p>
+ connection is still open, the user agent must <a href=#close-the-websocket-connection>close the WebSocket connection</a>.</p>
- <h4 id=websocket-protocol title="The Web Socket protocol enables
+ <h4 id=websocket-protocol title="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
@@ -67148,7 +67149,7 @@
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)."><span class=secno>10.3.4 </span>The Web Socket protocol</h4>
+ <iframe>s and long polling)."><span class=secno>10.3.4 </span>The WebSocket protocol</h4>
<h5 id=introduction-7><span class=secno>10.3.4.1 </span>Introduction</h5>
@@ -67176,8 +67177,8 @@
replies.</li>
</ul><p>A simpler solution would be to use a single TCP connection for
- traffic in both directions. This is what the Web Socket protocol
- provides. Combined with the Web Socket API, it provides an
+ traffic in both directions. This is what the WebSocket protocol
+ provides. Combined with the WebSocket API, it provides an
alternative to HTTP polling for two-way communication from a Web
page to a remote server.
</p>
@@ -67199,25 +67200,35 @@
<p>The handshake from the client looks as follows:</p>
<pre>GET /demo HTTP/1.1
+Host: example.com
+Connection: Upgrade
+Sec-WebSocket-Key2: 12998 5 Y3 1 .P00
+Sec-WebSocket-Protocol: sample
Upgrade: WebSocket
-Connection: Upgrade
-Host: example.com
+Sec-WebSocket-Key1: 4 @1 46546xW%0l 1 5
Origin: http://example.com
-WebSocket-Protocol: sample</pre>
+^n:ds[4U</pre>
+
<p>The handshake from the server looks as follows:</p>
- <pre>HTTP/1.1 101 Web Socket Protocol Handshake
+ <pre>HTTP/1.1 101 WebSocket Protocol Handshake
Upgrade: WebSocket
Connection: Upgrade
-WebSocket-Origin: http://example.com
-WebSocket-Location: ws://example.com/demo
-WebSocket-Protocol: sample</pre>
+Sec-WebSocket-Origin: http://example.com
+Sec-WebSocket-Location: ws://example.com/demo
+Sec-WebSocket-Protocol: sample
- <p>The first three lines in each case are hard-coded (the exact case
- and order matters); the remainder are an unordered <a href=#ascii-case-insensitive>ASCII
- case-insensitive</a> set of fields, one per line, that match the
- following non-normative ABNF:
+8jKS'y:G*Co,Wxa-</pre>
+
+ <p>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
+ the HTTP specification.</p>
+
+ <p>After the leading line in both cases come an unordered
+ <a href=#ascii-case-insensitive>ASCII case-insensitive</a> set of fields, one per line,
+ that each match the following non-normative ABNF:
<a href=#refsABNF>[ABNF]</a>
</p>
@@ -67232,13 +67243,20 @@
any-char = %x0000-0009 / %x000B-000C / %x000E-10FFFF
; a Unicode character other than U+000A LINE FEED (LF) or U+000D CARRIAGE RETURN (CR)</pre>
+ <p class=note>The character set for the above ABNF is Unicode. The
+ fields themselves are encoded as UTF-8.</p>
+
<p>Lines that don't match the above production cause the connection
to be aborted.</p>
- <p class=note>The character set for the above ABNF is Unicode. The
- headers themselves are encoded as UTF-8.</p>
+ <p>Finally, after the last field, the client sends 10 bytes
+ starting with 0x0D 0x0A and followed by 8 random bytes, part of a
+ challenge, and the server sends 18 bytes starting with 0x0D 0x0A and
+ followed by 16 bytes consisting of a challenge response. The details
+ of this challenge and other parts of the handshake are described in
+ the next section.</p>
- <p>Once the client and server have both sent their handshakes, and
+ <hr><p>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.</p>
@@ -67247,12 +67265,14 @@
with a 0x00 byte and ends with a 0xFF byte, with the UTF-8 text in
between.</p>
- <p>The Web Socket protocol uses this framing so that specifications
- that use the Web Socket protocol can expose such connections using
+ <p>The WebSocket protocol uses this framing so that specifications
+ that use the WebSocket 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.</p>
+ <!-- XXX Close Handshake -->
+
<p>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
@@ -67272,6 +67292,7 @@
</p>
+ <!-- XXX Close Handshake -->
<pre>; the wire protocol as allowed by this specification
frames = *frame
frame = text-frame
@@ -67289,6 +67310,11 @@
<p class=note>The above ABNF is intended for a binary octet
environment.</p>
+ <!-- XXX Close Handshake -->
+ <p class=warning>At this time, the WebSocket protocol cannot be
+ used to send binary data. Using any of the frame types other than
+ 0x00 is invalid.</p>
+
<hr><p>The following diagrams summarise the protocol:</p>
<pre>Handshake
@@ -67301,41 +67327,202 @@
`-- (0x80 to 0xFF) --> Length --> Data... ------->-'</pre>
- <h6 id=design-philosophy><span class=secno>10.3.4.1.3 </span>Design philosophy</h6>
+
+ <h6 id=handshake><span class=secno>10.3.4.1.3 </span>Handshake</h6>
+
<p><i>This section is non-normative.</i></p>
- <p>The Web Socket protocol is designed on the principle that there
+ <p>The handshake is intended to be compatible with HTTP-based
+ server-side software, so that a single port can be used by both HTTP
+ clients talking to that server and WebSocket clients talking to that
+ server. To this end, the WebSocket client's handshake appears to
+ HTTP servers to be a regular GET request with an Upgrade offer:</p>
+
+ <pre>GET /resource HTTP/1.1
+Upgrade: WebSocket
+Connection: Upgrade</pre>
+
+ <p>Additional fields are used to select options in the WebSocket
+ protocol. The only option available in this version is the
+ subprotocol selector, <code title=http-sec-websocket-protocol><a href=#sec-websocket-protocol>Sec-WebSocket-Protocol</a></code>:</p>
+
+ <pre>Sec-WebSocket-Protocol: chat</pre>
+
+ <p>This field indicates the subprotocol (the application-level
+ protocol layered over the WebSocket protocol) that the client
+ intends to use. The server echoes this field in its handshake to
+ indicate that it supports that subprotocol.</p>
+
+ <p>The remainder of the handshake is all security-related. First,
+ the <code title=http-host>Host</code> field is used to protect
+ against DNS rebinding attacks and to allow multiple domains to be
+ served from one IP address.</p>
+
+ <pre>Host: example.com</pre>
+
+ <p>The server includes the hostname in the <code title=http-sec-websocket-location><a href=#sec-websocket-location>Sec-WebSocket-Location</a></code>
+ field of its handshake, so that both the client and the server can
+ verify that they agree on which host is in use.</p>
+
+ <p>Second, the <code title=http-origin>Origin</code> field is
+ used to protect against unauthorized cross-origin use of a WebSocket
+ server by scripts using the <code><a href=#websocket>WebSocket</a></code> API in a Web
+ browser. The server specifies which origin it is willing to receive
+ requests from by including a <code title=http-sec-websocket-origin><a href=#sec-websocket-origin>Sec-WebSocket-Origin</a></code> field
+ with that origin. If multiple origins are authorized, the server
+ echoes the value in the <code title=http-origin>Origin</code>
+ field of the client's handshake.</p>
+
+ <pre>Origin: http://example.com</pre>
+
+ <p>Finally, the server has to prove to the client that it received
+ the client's WebSocket handshake, so that the server doesn't accept
+ connections that are not WebSocket connections. This prevents an
+ attacker from tricking a WebSocket server by sending it
+ carefully-crafted packets using <code>XMLHttpRequest</code> or a
+ <code><a href=#the-form-element>form</a></code> submission.</p>
+
+ <p>To prove that the handshake was received, the server has to take
+ three pieces of information and combine them to form a response. The
+ first two pieces of information come from the <code title=http-sec-websocket-key>Sec-WebSocket-Key1</code> and <code title=http-sec-websocket-key>Sec-WebSocket-Key2</code> fields in
+ the client handshake:</p>
+
+ <pre>Sec-WebSocket-Key1: 18x 6]8vM;54 *(5: { U1]8 z [ 8
+Sec-WebSocket-Key2: 1_ tx7X d < nw 334J702) 7]o}` 0</pre>
+
+ <p>For each of these fields, the server has to take the digits from
+ the value to obtain a number (in this case 1868545188 and 1733470270
+ respectively), then divide that number by the number of spaces
+ characters in the value (in this case 12 and 10) to obtain a 32-bit
+ number (155712099 and 173347027). These two resulting numbers are
+ then used in the server handshake, as described below.</p>
+
+ <p>The counting of spaces is intended to make it impossible to
+ smuggle this field into the resource name; making this even harder
+ is the presence of <em>two</em> such fields, and the use of a
+ newline as the only reliable indicator that the end of the key has
+ been reached. The use of random characters interspersed with the
+ spaces and the numbers ensures that the implementor actually looks
+ for spaces and newlines, instead of being treating any character
+ like a space, which would make it again easy to smuggle the fields
+ into the path and trick the server. Finally, <em>dividing</em> by
+ this number of spaces is intended to make sure that even the most
+ naïve of implementations will check for spaces, since if ther
+ server does not verify that there are some spaces, the server will
+ try to divide by zero, which is usually fatal (a correct handshake
+ will always have at least one space).
+
+ <p>The third piece of information is given after the fields, in the
+ last eight bytes of the handshake, expressed here as they would be
+ seen if interpreted as ASCII:</p>
+
+ <pre>Tm[K T2u</pre>
+
+ <p>The concatenation of the number obtained from processing the
+ <code title=http-sec-websocket-key>Sec-WebSocket-Key1</code>
+ field, expressed as a little-endian 32 bit number, the number
+ obtained from processing the <code title=http-sec-websocket-key>Sec-WebSocket-Key2</code> field,
+ again expressed as a little-endian 32 bit number, and finally the
+ eight bytes at the end of the handshake, form a 128 bit string whose
+ MD5 sum is then used by the server to prove that it read the
+ handshake.</p>
+
+ <hr><p>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 (the HTTP version and reason phrase aren't important):</p>
+
+ <pre>HTTP/1.1 101 WebSocket Protocol Handshake</pre>
+
+ <p>The fields follow. Two of the fields are just for compatibility
+ with HTTP:</p>
+
+ <pre>Upgrade: WebSocket
+Connection: Upgrade</pre>
+
+ <p>Two of the fields are part of the security model described
+ above, echoing the origin and stating the exact host, port, resource
+ name, and whether the connection is expected to be encrypted:</p>
+
+ <pre>Sec-WebSocket-Origin: http://example.com
+Sec-WebSocket-Location: ws://example.com/demo</pre>
+
+ <p>These fields are checked by the Web browser when it is acting as
+ a <code><a href=#websocket>WebSocket</a></code> client for scripted pages. A server that
+ only handles one origin and only serves one resource can therefore
+ just return hard-coded values and does not need to parse the
+ client's handshake to verify the correctness of the values.</p>
+
+ <p>Option fields can also be included. In this version of the
+ protocol, the only option field is <code title=http-sec-websocket-protocol><a href=#sec-websocket-protocol>Sec-WebSocket-Protocol</a></code>,
+ which indicates the subprotocol that the server speaks. Web browsers
+ verify that the server included the same value as was specified in
+ the <code><a href=#websocket>WebSocket</a></code> constructor, so a server that speaks
+ multiple subprotocols has to make sure it selects one based on the
+ client's handshake and specifies the right one in its handshake.</p>
+
+ <pre>Sec-WebSocket-Protocol: chat</pre>
+
+ <p>After the fields, the server sends the aforementioned MD5 sum, a
+ 16 byte (128 bit) value, shown here as if interpreted as ASCII:</p>
+
+ <pre>fQJ,fN/4F4!~K~MH</pre>
+
+ <p>This value depends on what the client sends, as described
+ above. If it doesn't match what the client is expecting, the client
+ would disconnect.</p>
+
+ <p>Having part of the handshake appear after the fields ensures
+ that both the server and the client verify that the connection is
+ not being interrupted by an HTTP intermediary such as a
+ man-in-the-middle cache or proxy.</p>
+
+
+
+ <h6 id=design-philosophy><span class=secno>10.3.4.1.4 </span>Design philosophy</h6>
+
+ <p><i>This section is non-normative.</i></p>
+
+ <p>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 Web Socket by the
+ 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/IP by the application layer (HTTP).</p>
+ of TCP by the application layer (HTTP).</p>
- <p>Conceptually, Web Socket is really just a layer on top of TCP/IP
+ <p>Conceptually, WebSocket is really just a layer on top of TCP
that adds a Web "origin"-based security model for browsers; adds an
addressing and protocol naming mechanism to support multiple
services on one port and multiple host names on one IP address; and
layers a framing mechanism on top of TCP to get back to the IP
packet mechanism that TCP is built on, but without length
- limits. Other than that, it adds nothing. Basically it is intended
- to be as close to just exposing raw TCP/IP to script as possible
+ limits.
+
+ <!-- XXX Close Handshake -->
+
+ 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.</p>
+ <p>The protocol is intended to be extensible; future versions will
+ likely introduce a mechanism to compress data and might support
+ sending binary data.</p>
- <h6 id=security-model><span class=secno>10.3.4.1.4 </span>Security model</h6>
+ <h6 id=security-model><span class=secno>10.3.4.1.5 </span>Security model</h6>
+
<p><i>This section is non-normative.</i></p>
- <p>The Web Socket protocol uses the origin model used by Web
- browsers to restrict which Web pages can contact a Web Socket server
- when the Web Socket protocol is used from a Web page. Naturally,
- when the Web 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.</p>
+ <p>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 useful, as the client can provide any arbitrary origin
+ string.</p>
<p>This protocol is intended to fail to establish a connection with
servers of pre-existing protocols like SMTP or HTTP, while allowing
@@ -67345,34 +67532,45 @@
the handshake is finished (thus limiting how much the server can be
influenced).</p>
+ <p>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 <code><a href=#the-form-element>form</a></code>
+ 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 <code title="">Sec-</code> cannot
+ be set by an attacker from a Web browser, even when using
+ <code>XMLHttpRequest</code>.</p>
- <h6 id=relationship-to-tcp/ip-and-http><span class=secno>10.3.4.1.5 </span>Relationship to TCP/IP and HTTP</h6>
+ <h6 id=relationship-to-tcp-and-http><span class=secno>10.3.4.1.6 </span>Relationship to TCP and HTTP</h6>
+
<p><i>This section is non-normative.</i></p>
- <p>The Web Socket protocol is an independent TCP-based protocol. Its
+ <p>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.</p>
<p>Based on the expert recommendation of the IANA<!-- [IANA #257455]
- -->, the Web Socket protocol by default uses port 80 for regular Web
- Socket connections and port 443 for Web Socket connections tunneled
+ -->, the WebSocket protocol by default uses port 80 for regular WebSocket connections and port 443 for WebSocket connections tunneled
over TLS.</p>
- <h6 id=establishing-a-connection><span class=secno>10.3.4.1.6 </span>Establishing a connection</h6>
+ <h6 id=establishing-a-connection><span class=secno>10.3.4.1.7 </span>Establishing a connection</h6>
<p><i>This section is non-normative.</i></p>
- <p>There are several options for establishing a Web Socket connection.</p>
+ <p>There are several options for establishing a WebSocket connection.</p>
<p>On the face of it, the simplest method would seem to be to use
- port 80 to get a direct connection to a Web Socket server. Port 80
- traffic, however, will often be intercepted by HTTP proxies, which
- can lead to the connection failing to be established.</p>
+ port 80 to get a direct connection to a WebSocket server. Port 80
+ traffic, however, will often be intercepted by man-in-the-middle
+ HTTP proxies, which can lead to the connection failing to be
+ established.</p>
<p>The most reliable method, therefore, is to use TLS encryption and
- port 443 to connect directly to a Web Socket server. This has the
+ port 443 to connect directly to a WebSocket server. This has the
advantage of being more secure; however, TLS encryption can be
computationally expensive.</p>
@@ -67382,94 +67580,26 @@
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 Web Socket protocol to be deployed. In more
+ 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 Web Socket connections separate from the
+ dedicated set of hosts for WebSocket connections separate from the
HTTP servers is probably easier to manage.</p>
- <h6 id=writing-a-simple-web-socket-server><span class=secno>10.3.4.1.7 </span>Writing a simple Web Socket server</h6>
- <p><i>This section is non-normative.</i></p>
+ <h6 id=subprotocols-using-the-websocket-protocol><span class=secno>10.3.4.1.8 </span>Subprotocols using the WebSocket protocol</h6>
- <p>If the Web Socket protocol is being used to provide a feature for
- a specific site, then the handshake can be hard-coded, and the data
- provided by the client in the handshake can be safely ignored. This
- section describes an implementation strategy for this case.</p>
-
- <p>Listen on a port for TCP/IP. Upon receiving a connection request,
- open a connection and send the following bytes back to the
- client:</p>
-
- <pre>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 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 57 65 62 53 6F 63 6B 65 74 2D 4F
-72 69 67 69 6E 3A 20</pre>
-
- <p>Send the <a href=#ascii-serialization-of-an-origin title="ASCII serialization of an origin">ASCII
- serialization</a> of the origin from which the server is willing
- to accept connections. <a href=#refsORIGIN>[ORIGIN]</a></p>
-
- <div class=example>
- <p>For example: <code title="">http://example.com</code></p>
- </div>
-
- <p>Continue by sending the following bytes back to the client:</p>
-
- <pre>0D 0A 57 65 62 53 6F 63 6B 65 74 2D 4C 6F 63 61
-74 69 6F 6E 3A 20</pre>
-
- <p>Send the <a href=#url>URL</a> of the Web Socket script.</p>
-
- <div class=example>
- <p>For example: <code title="">ws://example.com/demo</code></p>
- </div>
-
- <p>Finish the handshake by sending the four bytes 0x0D 0x0A 0x0D
- 0x0A to the client. Then, read data <em>from</em> the client until
- four bytes 0x0D 0x0A 0x0D 0x0A are read.</p>
-
- <p class=note>User agents will drop the connection after the
- handshake if the origin and URL sent as part of the algorithm above
- 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.</p>
-
- <p>At this point, there are two concerns: receiving frames and
- sending frames.</p>
-
- <p>To receive a frame, read a byte, verify that it is a 0x00 byte,
- then read bytes until you find a 0xFF byte, and interpret all the
- bytes between the 0x00 and 0xFF bytes as a UTF-8 string (the frame
- payload, or message). This process can be repeated as necessary. If
- at any point the first byte of one of these sequences is not 0x00,
- then an error has occurred, and closing the connection is the
- appropriate response.</p>
-
- <p>To send a frame, first send a 0x00 byte, then send the message as
- a UTF-8 string, then send a 0xFF byte. Again, this process can be
- repeated as necessary.</p>
-
- <p>The connection can be closed as desired.</p>
-
-
- <h6 id=subprotocols-using-the-web-socket-protocol><span class=secno>10.3.4.1.8 </span>Subprotocols using the Web Socket protocol</h6>
-
<p><i>This section is non-normative.</i></p>
<p>The client can request that the server use a specific subprotocol
- by including the <code title=http-websocket-protocol><a href=#websocket-protocol-0>Websocket-Protocol</a></code> header in
- its handshake. If it is specified, the server needs to include the
- same header and value in its response for the connection to be
- established.</p>
+ by including the <code title=http-sec-websocket-protocol><a href=#sec-websocket-protocol>Sec-Websocket-Protocol</a></code>
+ field in its handshake. If it is specified, the server needs to
+ include the same field and value in its response for the connection
+ to be established.</p>
<p>These subprotocol names do not need to be registered, but if a
subprotocol is intended to be implemented by multiple independent
- Web Socket servers, potential clashes with the names of subprotocols
+ WebSocket servers, potential clashes with the names of subprotocols
defined independently can be avoided by using names that contain the
domain name of the subprotocol's originator. For example, if Example
Corporation were to create a Chat subprotocol to be implemented by
@@ -67483,7 +67613,7 @@
<p>Subprotocols can be versioned in backwards-incompatible ways by
changing the subprotocol name, eg. going from "bookings.example.net"
to "bookings.example.net2". These subprotocols would be considered
- completely separate by Web Socket clients. Backwards-compatible
+ completely separate by WebSocket clients. Backwards-compatible
versioning can be implemented by reusing the same subprotocol string
but carefully designing the actual subprotocol to support this kind
of extensibility.</p>
@@ -67494,16 +67624,16 @@
<p>When an implementation is required to <i>send</i> data as part of
- the Web Socket protocol, the implementation may delay the actual
+ the WebSocket protocol, the implementation may delay the actual
transmission arbitrarily, e.g. buffering data so as to send fewer IP
packets.</p>
- <h5 id=web-socket-urls><span class=secno>10.3.4.2 </span>Web Socket URLs</h5>
+ <h5 id=websocket-urls><span class=secno>10.3.4.2 </span>WebSocket URLs</h5>
- <h6 id=parsing-web-socket-urls><span class=secno>10.3.4.2.1 </span>Parsing Web Socket URLs</h6>
+ <h6 id=parsing-websocket-urls><span class=secno>10.3.4.2.1 </span>Parsing WebSocket URLs</h6>
- <p>The steps to <dfn id="parse-a-web-socket-url's-components">parse a Web Socket URL's components</dfn> from
+ <p>The steps to <dfn id="parse-a-websocket-url's-components">parse a WebSocket URL's components</dfn> from
a string <var title="">url</var> are as follows. These steps return
either a <var title="">host</var>, a <var title="">port</var>, a
<var title="">resource name</var>, and a <var title="">secure</var>
@@ -67565,9 +67695,9 @@
<li><p>Return <var title="">host</var>, <var title="">port</var>,
<var title="">resource name</var>, and <var title="">secure</var>.</li>
- </ol><h6 id=constructing-web-socket-urls><span class=secno>10.3.4.2.2 </span>Constructing Web Socket URLs</h6>
+ </ol><h6 id=constructing-websocket-urls><span class=secno>10.3.4.2.2 </span>Constructing WebSocket URLs</h6>
- <p>The steps to <dfn id=construct-a-web-socket-url>construct a Web Socket URL</dfn> from a <var title="">host</var>, a <var title="">port</var>, a <var title="">resource name</var>, and a <var title="">secure</var> flag,
+ <p>The steps to <dfn id=construct-a-websocket-url>construct a WebSocket URL</dfn> from a <var title="">host</var>, a <var title="">port</var>, a <var title="">resource name</var>, and a <var title="">secure</var> flag,
are as follows:</p>
<ol><li>Let <var title="">url</var> be the empty string.</li>
@@ -67596,9 +67726,9 @@
establish to a server.</p>
- <h6 id=handshake><span class=secno>10.3.4.3.1 </span>Handshake</h6>
+ <h6 id=handshake-0><span class=secno>10.3.4.3.1 </span>Handshake</h6>
- <p>When the user agent is to <dfn id=establish-a-web-socket-connection>establish a Web Socket
+ <p>When the user agent is to <dfn id=establish-a-websocket-connection>establish a WebSocket
connection</dfn> to a host <var title="">host</var>, on a port <var title="">port</var>, from an origin whose <a href=#ascii-serialization-of-an-origin title="ASCII
serialization of an origin">ASCII serialization</a> is <var title="">origin</var>, with a flag <var title="">secure</var>, with
a string giving a <var title="">resource name</var>, and optionally
@@ -67613,19 +67743,18 @@
<ol><li>
- <p>If the user agent already has a Web Socket connection to the
+ <p>If the user agent already has a WebSocket connection to the
remote host (IP address) identified by <var title="">host</var>,
even if known by another name, wait until that connection has been
- <a href=#web-socket-connection-is-established title="Web Socket connection is
+ <a href=#websocket-connection-is-established title="WebSocket connection is
established">established</a> or for that connection to have
- <a href=#fail-the-web-socket-connection title="fail the Web Socket connection">failed</a>.</p>
+ <a href=#fail-the-websocket-connection title="fail the WebSocket connection">failed</a>.</p>
<p class=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.</p>
+ denial of service attack by just opening a large number of WebSocket connections to a remote host.</p>
- <p class=note>There is no limit to the number of <a href=#web-socket-connection-is-established title="Web Socket connection is established">established</a>
- Web Socket connections a user agent can have with a single remote
+ <p class=note>There is no limit to the number of <a href=#websocket-connection-is-established title="WebSocket connection is established">established</a>
+ WebSocket 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.</p>
@@ -67635,8 +67764,8 @@
<li>
<p><i>Connect</i>: If the user agent is configured to use a proxy
- when using the Web Socket protocol to connect to host <var title="">host</var> and/or port <var title="">port</var>, then
- connect to that proxy and ask it to open a TCP/IP connection to
+ when using the WebSocket protocol to connect to host <var title="">host</var> and/or port <var title="">port</var>, then
+ connect to that proxy and ask it to open a TCP connection to
the host given by <var title="">host</var> and the port given by
<var title="">port</var>.</p>
@@ -67659,11 +67788,11 @@
</div>
<p>Otherwise, if the user agent is not configured to use a proxy,
- then open a TCP/IP connection to the host given by <var title="">host</var> and the port given by <var title="">port</var>.</p>
+ then open a TCP connection to the host given by <var title="">host</var> and the port given by <var title="">port</var>.</p>
<p class=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
+ 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.</p>
@@ -67671,22 +67800,22 @@
<p>For the purpose of proxy autoconfiguration scripts, the
<a href=#url>URL</a> to pass the function must be constructed from
<var title="">host</var>, <var title="">port</var>, <var title="">resource name</var>, and the <var title="">secure</var>
- flag using the steps to <a href=#construct-a-web-socket-url>construct a Web Socket
+ flag using the steps to <a href=#construct-a-websocket-url>construct a WebSocket
URL</a>.</p>
- <p class=note>The Web Socket protocol can be identified in proxy
+ <p class=note>The WebSocket protocol can be identified in proxy
autoconfiguration scripts from the scheme ("<code title="">ws:</code>" for unencrypted connections and "<code title="">wss:</code>" for encrypted connections).</p>
</li>
- <li><p>If the connection could not be opened, then <a href=#fail-the-web-socket-connection>fail the
- Web Socket connection</a> and abort these steps.</li>
+ <li><p>If the connection could not be opened, then <a href=#fail-the-websocket-connection>fail the
+ WebSocket connection</a> and abort these steps.</li>
<li>
<p>If <var title="">secure</var> is true, perform a TLS handshake
over the connection. If this fails (e.g. the server's certificate
- could not be verified), then <a href=#fail-the-web-socket-connection>fail the Web Socket
+ could not be verified), then <a href=#fail-the-websocket-connection>fail the WebSocket
connection</a> and abort these steps. Otherwise, all further
communication on this channel must run through the encrypted
tunnel. <a href=#refsRFC2246>[RFC2246]</a></p>
@@ -67698,89 +67827,80 @@
<li>
- <p>Send the following bytes to the remote side (the server):</p>
+ <p>Send the UTF-8 string "GET" followed by a UTF-8-encoded U+0020
+ SPACE character to the remote side (the server).</p>
- <pre>47 45 54 20</pre>
-
<p>Send the <var title="">resource name</var> value, encoded as
- ANSI_X3.4-1968 (US-ASCII). <a href=#refsRFC1345>[RFC1345]</a></p>
+ UTF-8.</p>
- <p>Send the following bytes:</p>
+ <p>Send another UTF-8-encoded U+0020 SPACE character, followed by
+ the UTF-8 string "HTTP/1.1", followed by a UTF-8-encoded U+000D
+ CARRIAGE RETURN U+000A LINE FEED character pair (CRLF).</p>
- <pre>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</pre>
+ </li>
- <p class=note>The string "GET ", the path,
- " HTTP/1.1", CRLF, the string "Upgrade: WebSocket",
- CRLF, and the string "Connection: Upgrade", CRLF.</p>
+ <li>
+ <p>Let <var title="">fields</var> be an empty list of strings.</p>
+
</li>
<li>
- <p>Send the following bytes:</p>
+ <p>Add the string "Upgrade: WebSocket" to <var title="">fields</var>.</p>
- <pre>48 6F 73 74 3A 20</pre>
+ </li>
- <p>Send the <var title="">host</var> value, <a href=#converted-to-ascii-lowercase>converted to
- ASCII lowercase</a>, and encoded as ANSI_X3.4-1968
- (US-ASCII). <a href=#refsRFC1345>[RFC1345]</a></p>
+ <li>
- <p>If <var title="">secure</var> is false, and <var title="">port</var> is not 80, or if <var title="">secure</var> is
- true, and <var title="">port</var> is not 443, then send an 0x3A
- byte (ASCII :) followed by the value of <var title="">port</var>,
- expressed as a base-ten integer, encoded as ANSI_X3.4-1968
- (US-ASCII). <a href=#refsRFC1345>[RFC1345]</a></p>
+ <p>Add the string "Connection: Upgrade" to <var title="">fields</var>.</p>
- <p>Send the following bytes:</p>
+ </li>
- <pre>0D 0A</pre>
+ <li>
- <p class=note>The string "Host: ", the host, and CRLF.</p>
+ <p>Let <var title="">hostport</var> be an empty string.</p>
</li>
<li>
- <p>Send the following bytes:</p>
+ <p>Append the <var title="">host</var> value, <a href=#converted-to-ascii-lowercase>converted to
+ ASCII lowercase</a>, to <var title="">hostport</var>.</p>
- <pre>4F 72 69 67 69 6E 3A 20</pre>
+ </li>
- <p>Send the <var title="">origin</var> value, <a href=#converted-to-ascii-lowercase>converted to
- ASCII lowercase</a>, encoded as ANSI_X3.4-1968 (US-ASCII). <a href=#refsORIGIN>[ORIGIN]</a> <a href=#refsRFC1345>[RFC1345]</a></p>
+ <li>
- <p class=note>The <var title="">origin</var> value is a string
- that was passed to this algorithm.</p>
+ <p>If <var title="">secure</var> is false, and <var title="">port</var> is not 80, or if <var title="">secure</var> is
+ true, and <var title="">port</var> is not 443, then append a
+ U+003A COLON character (:) followed by the value of <var title="">port</var>, expressed as a base-ten integer, to <var title="">hostport</var>.</p>
- <p>Send the following bytes:</p>
+ </li>
- <pre>0D 0A</pre>
+ <li>
- <p class=note>The string "Origin: ", the origin, and CRLF.</p> <!-- http-origin -->
+ <p>Add the string consisting of the concatenation of the string
+ "Host:", a U+0020 SPACE character, and <var title="">hostport</var>, to <var title="">fields</var>.</p>
</li>
<li>
- <p>If there is no <var title="">protocol</var>, then skip this step.</p>
+ <p>Add the string consisting of the concatenation of the string
+ "Origin:", a U+0020 SPACE character, and the <var title="">origin</var> value, <a href=#converted-to-ascii-lowercase>converted to ASCII
+ lowercase</a>, to <var title="">fields</var>.</p>
- <p>Otherwise, send the following bytes:</p>
+ </li>
- <pre>57 65 62 53 6F 63 6B 65 74 2D 50 72 6F 74 6F 63
-6F 6C 3A 20</pre>
+ <li>
- <p>Send the <var title="">protocol</var> value, encoded as
- ANSI_X3.4-1968 (US-ASCII). <a href=#refsRFC1345>[RFC1345]</a></p>
+ <p>If there is no <var title="">protocol</var>, then skip this step.</p>
- <p>Send the following bytes:</p>
+ <p>Otherwise, add the string consisting of the concatenation of
+ the string "Sec-WebSocket-Protocol:", a U+0020 SPACE character,
+ and the <var title="">protocol</var> value, to <var title="">fields</var>.</p>
- <pre>0d 0a</pre>
-
- <p class=note>The string "WebSocket-Protocol: ", the
- protocol, and CRLF.</p>
-
</li>
<li>
@@ -67789,30 +67909,25 @@
information or--> cookies that would be relevant to a resource
accessed over HTTP, if <var title="">secure</var> is false, or
HTTPS, if it is true, on host <var title="">host</var>, port <var title="">port</var>, with <var title="">resource name</var> as the
- path (and possibly query parameters), then HTTP headers that would
- be appropriate for that information should be sent at this point.
+ path (and possibly query parameters), then add to <var title="">fields</var> any HTTP headers that would be appropriate
+ for that information.
<a href=#refsHTTP>[HTTP]</a>
<a href=#refsCOOKIES>[COOKIES]</a>
</p>
<p>This includes "<code>HttpOnly</code>" cookies (cookies with the
- http-only-flag set to true); the Web Socket protocol is not
- considered a non-HTTP API.</p>
+ http-only-flag set to true); the WebSocket protocol is not
+ considered a non-HTTP API for the purpose of cookie
+ processing.</p>
- <p>Each header must be on a line of its own (each ending with a
- CRLF sequence). For the purposes of this step, each header must
- not be split into multiple lines (despite HTTP otherwise allowing
- this with continuation lines).</p>
-
<!--(v2-ws-auth)
<div class="example">
<p>For example, if the server had a username and password that
applied to <code title="">http://example.com/socket</code>, and
- the Web Socket was being opened to <code
- title="">ws://example.com/socket</code>, it could send
- them:</p>
+ the WebSocket was being opened to <code
+ title="">ws://example.com/socket</code>, it could add them:</p>
<pre>Authorization: Basic d2FsbGU6ZXZl</pre>
@@ -67823,119 +67938,221 @@
<li>
- <p>Send the following bytes:</p>
+ <p>Let <var title="">spaces<sub>1</sub></var> be a random integer
+ from 1 to 12 inclusive.</p>
- <pre>0d 0a</pre>
+ <p>Let <var title="">spaces<sub>2</sub></var> be a random integer
+ from 1 to 12 inclusive.</p>
- <p class=note>Just a CRLF (a blank line).</p>
+ <p class=example>For example, 5 and 9.</p>
</li>
<li>
- <p>Read bytes from the server until either the connection closes,
- or a 0x0A byte is read. Let <var title="">header</var> be these
- bytes, including the 0x0A byte.</p>
+ <p>Let <var title="">max<sub>1</sub></var> be the largest integer
+ not greater than 4,294,967,295 divided by <var title="">spaces<sub>1</sub></var>.</p>
- <p>If <var title="">header</var> is not at least two bytes long,
- or if the last two bytes aren't 0x0D and 0x0A respectively, then
- <a href=#fail-the-web-socket-connection>fail the Web Socket connection</a> and abort these
- steps.</p>
+ <p>Let <var title="">max<sub>2</sub></var> be the largest integer
+ not greater than 4,294,967,295 divided by <var title="">spaces<sub>2</sub></var>.</p>
- <p>User agents may apply a timeout to this step, <a href=#fail-the-web-socket-connection title="fail
- the Web Socket connection">failing the Web Socket
- connection</a> if the server does not send back data in a
- suitable time period.</p>
+ <p class=example>Continuing the example, 858,993,459 and 477,218,588.</p>
</li>
<li>
- <p>If <var title="">header</var> consists of 44 bytes that exactly
- match the following, then let <var title="">mode</var> be <i title="">normal</i>.</p>
+ <p>Let <var title="">number<sub>1</sub></var> be a random integer
+ from 0 to <var title="">max<sub>1</sub></var> inclusive.</p>
- <pre>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</pre>
+ <p>Let <var title="">number<sub>2</sub></var> be a random integer
+ from 0 to <var title="">max<sub>2</sub></var> inclusive.</p>
- <p class=note>The string
- "HTTP/1.1 101 Web Socket Protocol Handshake"
- followed by a CRLF pair.</p>
+ <p class=example>For example, 777,007,543 and 114,997,259.</p>
- <p class=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.</p> <!-- we might update this as HTTP is updated,
- depending on whether it remains compatible or whatnot -->
+ </li>
- <p>Otherwise, let <var title="">code</var> be the substring of
- <var title="">header</var> that starts 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 <var title="">header</var>, then <a href=#fail-the-web-socket-connection>fail the Web Socket
- connection</a> and abort these steps.</p>
+ <li>
-<!--(v2-redirect)
- <p>If <var title="">code</var>, interpreted as ANSI_X3.4-1968
- (US-ASCII), is either "<code title="">301</code>", "<code
- title="">302</code>", "<code title="">303</code>", "<code
- title="">307</code>", then let <var title="">mode</var> be <i
- title="">redirect</i>. <a href="#refsRFC1345">[RFC1345]</a></p>
--->
-<!--(v2-ws-auth)
- <p>If <var title="">code</var>, interpreted as ANSI_X3.4-1968
- (US-ASCII), is "<code title="">401</code>", then let <var
- title="">mode</var> be <i title="">authenticate</i>. <a
- href="#refsRFC1345">[RFC1345]</a></p>
--->
+ <p>Let <var title="">product<sub>1</sub></var> be the result of
+ multiplying <var title="">number<sub>1</sub></var> and <var title="">spaces<sub>1</sub></var> together.</p>
- <p>If <var title="">code</var>, interpreted as ANSI_X3.4-1968
- (US-ASCII), is "<code title="">407</code>", then either close the
- connection and jump back to step 2, providing appropriate
- authentication information, or <a href=#fail-the-web-socket-connection>fail the Web Socket
- connection</a>. 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 <code title=http-Proxy-Authenticate>Proxy-Authenticate</code>
- header). <a href=#refsRFC1345>[RFC1345]</a></p>
+ <p>Let <var title="">product<sub>2</sub></var> be the result of
+ multiplying <var title="">number<sub>2</sub></var> and <var title="">spaces<sub>2</sub></var> together.</p>
- <p>Otherwise, <a href=#fail-the-web-socket-connection>fail the Web Socket connection</a> and
- abort these steps.</p>
+ <p class=example>Continuing the example, 3,885,037,715 and
+ 1,034,975,331.</p>
</li>
<li>
- <p>If <var title="">mode</var> is <i title="">normal</i>, then
- read 41 bytes from the server.</p>
+ <p>Let <var title="">key<sub>1</sub></var> be a string consisting
+ of <var title="">product<sub>1</sub></var>, expressed in base ten
+ using the numerals in the range U+0030 DIGIT ZERO (0) to U+0039
+ DIGIT NINE (9).</p>
- <p>If the connection closes before 41 bytes are received, or if
- the 41 bytes aren't exactly equal to the following bytes, then
- <a href=#fail-the-web-socket-connection>fail the Web Socket connection</a> and abort these
- steps.</p>
+ <p>Let <var title="">key<sub>2</sub></var> be a string consisting
+ of <var title="">product<sub>2</sub></var>, expressed in base ten
+ using the numerals in the range U+0030 DIGIT ZERO (0) to U+0039
+ DIGIT NINE (9).</p>
- <pre>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</pre>
+ <p class=example>Continuing the example, "3885037715" and
+ "1034975331".</p>
- <p class=note>The string "Upgrade: WebSocket", CRLF, the
- string "Connection: Upgrade", CRLF.</p>
+ </li>
- <p>User agents may apply a timeout to this step, <a href=#fail-the-web-socket-connection title="fail
- the Web Socket connection">failing the Web Socket
- connection</a> if the server does not respond with the above
- bytes within a suitable time period.</p>
+ <li>
-<!--(v2-ws-auth) (v2-redirect)
- <p class="note">This step is skipped if <var title="">mode</var>
- is <i title="">redirect</i> or <i title="">authenticate</i>.</p>
+ <p>Insert <var title="">spaces<sub>1</sub></var> U+0020 SPACE
+ characters into <var title="">key<sub>1</sub></var> at random
+ positions.</p>
+
+ <p>Insert <var title="">spaces<sub>2</sub></var> U+0020 SPACE
+ characters into <var title="">key<sub>2</sub></var> at random
+ positions.</p>
+
+ <p class=example>Continuing the example, this could lead to
+ "388 5037 7 15" and
+ "1 0 3 4 97 53 31".</p>
+
+ </li>
+
+ <li>
+
+ <p>Insert between one and twelve random characters from
+ the ranges U+0021 to U+002F and U+003A to U+007E into <var title="">key<sub>1</sub></var> at random positions.</p>
+
+ <p>Insert between one and twelve random characters from
+ the ranges U+0021 to U+002F and U+003A to U+007E into <var title="">key<sub>2</sub></var> at random positions.</p>
+
+ <p class=note>This corresponds to random printable ASCII
+ characters other than the digits and the U+0020 SPACE
+ character.</p>
+
+ <p class=example>Continuing the example, this could lead to
+ "388P O503D&ul7 {K%gX( %7 15" and
+ "1 N ?|k UT0or 3o 4 I97N 5-S3O 31".</p>
+
+ </li>
+
+ <li>
+
+ <p>Add the string consisting of the concatenation of the string
+ "Sec-WebSocket-Key1:", a U+0020 SPACE character, and the <var title="">key<sub>1</sub></var> value, to <var title="">fields</var>.</p>
+
+ <p>Add the string consisting of the concatenation of the string
+ "Sec-WebSocket-Key2:", a U+0020 SPACE character, and the <var title="">key<sub>2</sub></var> value, to <var title="">fields</var>.</p>
+
+ </li>
+
+ <li>
+
+ <p>For each string in <var title="">fields</var>, in a random
+ order: send the string, encoded as UTF-8, followed by a
+ UTF-8-encoded U+000D CARRIAGE RETURN U+000A LINE FEED character
+ pair (CRLF). It is important that the fields be output in a
+ random order so that servers not depend on the particular order
+ used by any particular client.</p>
+
+ </li>
+
+ <li>
+
+ <p>Send a UTF-8-encoded U+000D CARRIAGE RETURN U+000A LINE FEED
+ character pair (CRLF).</p>
+
+ </li>
+
+ <li>
+
+ <p>Let <var title="">key3</var> be a string consisting of eight
+ random bytes (or equivalently, a random 64 bit integer encoded in
+ little-endian order).</p>
+
+ <p class=example>For example, 0x47 0x30 0x22 0x2D 0x5A 0x3F 0x47
+ 0x58.</p>
+
+ </li>
+
+ <li>
+
+ <p>Send <var title="">key3</var> to the server.</p>
+
+ </li>
+
+ <li>
+
+ <p>Read bytes from the server until either the connection closes,
+ or a 0x0A byte is read. Let <var title="">field</var> be these
+ bytes, including the 0x0A byte.</p>
+
+ <p>If <var title="">field</var> is not at least seven bytes long,
+ or if the last two bytes aren't 0x0D and 0x0A respectively, or if
+ it does not contain at least two 0x20 bytes, then <a href=#fail-the-websocket-connection>fail the
+ WebSocket connection</a> and abort these steps.</p>
+
+ <p>User agents may apply a timeout to this step, <a href=#fail-the-websocket-connection title="fail
+ the WebSocket connection">failing the WebSocket
+ connection</a> if the server does not send back data in a
+ suitable time period.</p>
+
+ </li>
+
+ <li>
+
+ <p>Let <var title="">code</var> be the substring of <var title="">field</var> that starts from the byte after the first
+ 0x20 byte, and ends with the byte before the second 0x20 byte.</p>
+
+ </li>
+
+ <li>
+
+ <p>If <var title="">code</var> is not three bytes long, or if any
+ of the bytes in <var title="">code</var> are not in the range 0x30
+ to 0x39, then <a href=#fail-the-websocket-connection>fail the WebSocket connection</a> and abort
+ these steps.</p>
+
+ </li>
+
+ <li>
+
+<!--(v2-redirect or v2-ws-auth) - - then change the text below
+ <p>If <var title="">code</var>, interpreted as UTF-8, is "101",
+ then let <var title="">mode</var> be <i title="">normal</i>.</p>
-->
+<!--(v2-redirect)
+ <p>If <var title="">code</var>, interpreted as UTF-8, is either
+ "<code title="">301</code>", "<code title="">302</code>", "<code
+ title="">303</code>", "<code title="">307</code>", then let <var
+ title="">mode</var> be <i title="">redirect</i>.</p>
+-->
+<!--(v2-ws-auth)
+ <p>If <var title="">code</var>, interpreted as UTF-8, is "<code
+ title="">401</code>", then let <var title="">mode</var> be <i
+ title="">authenticate</i>.</p>
+-->
+ <p>If <var title="">code</var>, interpreted as UTF-8, is "101",
+ then move to the next step.</p>
+
+ <p>If <var title="">code</var>, interpreted as UTF-8, is "<code title="">407</code>", then either close the connection and jump
+ back to step 2, providing appropriate authentication information,
+ or <a href=#fail-the-websocket-connection>fail the WebSocket connection</a>. 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 <code title=http-Proxy-Authenticate>Proxy-Authenticate</code>
+ header).</p>
+
+ <p>Otherwise, <a href=#fail-the-websocket-connection>fail the WebSocket connection</a> and abort
+ these steps.</p>
+
</li>
- <li><p>Let <var title="">headers</var> be a list of name-value
+ <li><p>Let <var title="">fields</var> be a list of name-value
pairs, initially empty.</li>
- <li id=ws-ua-header-loop><p><i title="">Header</i>: Let <var title="">name</var> and <var title="">value</var> be empty byte
+ <li id=ws-ua-field-loop><p><i title="">Field</i>: Let <var title="">name</var> and <var title="">value</var> be empty byte
arrays.</li>
<li>
@@ -67943,7 +68160,7 @@
<p>Read a byte from the server.</p>
<p>If the connection closes before this byte is received, then
- <a href=#fail-the-web-socket-connection>fail the Web Socket connection</a> and abort these
+ <a href=#fail-the-websocket-connection>fail the WebSocket connection</a> and abort these
steps.</p>
<p>Otherwise, handle the byte as described in the appropriate
@@ -67952,14 +68169,14 @@
<dl class=switch><dt>If the byte is 0x0D (ASCII CR)</dt>
<dd>If the <var title="">name</var> byte array is empty, then
- jump to the <a href=#ws-ua-headers-processing>headers
- processing</a> step. Otherwise, <a href=#fail-the-web-socket-connection>fail the Web Socket
+ jump to the <a href=#ws-ua-fields-processing>fields
+ processing</a> step. Otherwise, <a href=#fail-the-websocket-connection>fail the WebSocket
connection</a> and abort these steps.</dd>
<dt>If the byte is 0x0A (ASCII LF)</dt>
- <dd><a href=#fail-the-web-socket-connection>Fail the Web Socket connection</a> and abort these
+ <dd><a href=#fail-the-websocket-connection>Fail the WebSocket connection</a> and abort these
steps.</dd>
@@ -67980,7 +68197,7 @@
<dd>Append the byte to the <var title="">name</var> byte
array and redo this step for the next byte.</dd>
- </dl><p class=note>This reads a header name, terminated by a colon,
+ </dl><p class=note>This reads a field name, terminated by a colon,
converting upper-case ASCII letters to lowercase, and aborting if
a stray CR or LF is found.</p>
@@ -67991,7 +68208,7 @@
<p>Read a byte from the server.</p>
<p>If the connection closes before this byte is received, then
- <a href=#fail-the-web-socket-connection>fail the Web Socket connection</a> and abort these
+ <a href=#fail-the-websocket-connection>fail the WebSocket connection</a> and abort these
steps.</p>
<p>Otherwise, handle the byte as described in the appropriate
@@ -68017,7 +68234,7 @@
<p>Read a byte from the server.</p>
<p>If the connection closes before this byte is received, then
- <a href=#fail-the-web-socket-connection>fail the Web Socket connection</a> and abort these
+ <a href=#fail-the-websocket-connection>fail the WebSocket connection</a> and abort these
steps.</p>
<p>Otherwise, handle the byte as described in the appropriate
@@ -68030,7 +68247,7 @@
<dt>If the byte is 0x0A (ASCII LF)</dt>
- <dd><a href=#fail-the-web-socket-connection>Fail the Web Socket connection</a> and abort these
+ <dd><a href=#fail-the-websocket-connection>Fail the WebSocket connection</a> and abort these
steps.</dd>
@@ -68039,7 +68256,7 @@
<dd>Append the byte to the <var title="">value</var> byte array
and redo this step for the next byte.</dd>
- </dl><p class=note>This reads a header value, terminated by a
+ </dl><p class=note>This reads a field value, terminated by a
CRLF.</p>
</li>
@@ -68049,17 +68266,16 @@
<p>Read a byte from the server.</p>
<p>If the connection closes before this byte is received, or if
- the byte is not a 0x0A byte (ASCII LF), then <a href=#fail-the-web-socket-connection>fail the Web
- Socket connection</a> and abort these steps.</p>
+ the byte is not a 0x0A byte (ASCII LF), then <a href=#fail-the-websocket-connection>fail the WebSocket connection</a> and abort these steps.</p>
<p class=note>This skips past the LF byte of the CRLF after the
- header.</p>
+ field.</p>
</li>
<li>
- <p>Append an entry to the <var title="">headers</var> list that
+ <p>Append an entry to the <var title="">fields</var> list that
has the name given by the string obtained by interpreting the <var title="">name</var> byte array as a UTF-8 byte stream and the
value given by the string obtained by interpreting the <var title="">value</var> byte array as a UTF-8 byte stream.</p>
@@ -68067,69 +68283,87 @@
<li>
- <p>Return to the "<a href=#ws-ua-header-loop>Header</a>" step
+ <p>Return to the "<a href=#ws-ua-field-loop>Field</a>" step
above.</p>
</li>
- <li id=ws-ua-headers-processing>
+ <li id=ws-ua-fields-processing>
- <p><i>Headers processing</i>: Read a byte from the server.</p>
+ <p><i>Fields processing</i>: Read a byte from the server.</p>
<p>If the connection closes before this byte is received, or if
- the byte is not a 0x0A byte (ASCII LF), then <a href=#fail-the-web-socket-connection>fail the Web
- Socket connection</a> and abort these steps.</p>
+ the byte is not a 0x0A byte (ASCII LF), then <a href=#fail-the-websocket-connection>fail the WebSocket connection</a> and abort these steps.</p>
<p class=note>This skips past the LF byte of the CRLF after the
- blank line after the headers.</p>
+ blank line after the fields.</p>
</li>
<li>
- <p>If <var title="">mode</var> is <i title="">normal</i>, then: If
- there is not exactly one entry in the <var title="">headers</var>
- list whose name is "<code title=http-websocket-origin><a href=#websocket-origin>websocket-origin</a></code>", or if
- there is not exactly one entry in the <var title="">headers</var>
- list whose name is "<code title=http-websocket-location><a href=#websocket-location>websocket-location</a></code>", or if
- the <var title="">protocol</var> was specified but there is not
- exactly one entry in the <var title="">headers</var> list whose
- name is "<code title=http-websocket-protocol><a href=#websocket-protocol-0>websocket-protocol</a></code>", or if
- there are any entries in the <var title="">headers</var> list
- whose names are the empty string, then <a href=#fail-the-web-socket-connection>fail the Web Socket
+ <p>
+ <!--(v2-redirect or v2-ws-auth) If <var title="">mode</var> is <i title="">normal</i>, then: -->
+
+ If there is not exactly one entry in the <var title="">fields</var> list whose name is "<code title=http-upgrade>upgrade</code>", or
+
+ if there is not exactly one entry in the <var title="">fields</var> list whose name is "<code title=http-connection>connection</code>", or
+
+ if there is not exactly one entry in the <var title="">fields</var> list whose name is "<code title=http-sec-websocket-origin><a href=#sec-websocket-origin>sec-websocket-origin</a></code>", or
+
+ if there is not exactly one entry in the <var title="">fields</var> list whose name is "<code title=http-sec-websocket-location><a href=#sec-websocket-location>sec-websocket-location</a></code>", or
+
+ if the <var title="">protocol</var> was specified but there is not exactly one entry in the <var title="">fields</var> list whose name is "<code title=http-sec-websocket-protocol><a href=#sec-websocket-protocol>sec-websocket-protocol</a></code>", or
+
+ if there are any entries in the <var title="">fields</var> list
+ whose names are the empty string, then <a href=#fail-the-websocket-connection>fail the WebSocket
connection</a> and abort these steps. Otherwise, handle each
- entry in the <var title="">headers</var> list as follows:</p>
+ entry in the <var title="">fields</var> list as follows:</p>
- <dl class=switch><dt>If the entry's name is "<code title=http-websocket-origin><a href=#websocket-origin>websocket-origin</a></code>"</dt>
+ <dl class=switch><dt>If the entry's name is "<code title=http-upgrade>upgrade</code>"</dt>
+ <dd><p>If the value is not exactly equal to the string
+ "WebSocket", then <a href=#fail-the-websocket-connection>fail the WebSocket connection</a> and
+ abort these steps.</dd>
+
+
+ <dt>If the entry's name is "<code title=http-connection>connection</code>"</dt>
+
+ <dd><p>If the value, <a href=#converted-to-ascii-lowercase>converted to ASCII lowercase</a>,
+ is not exactly equal to the string "upgrade", then <a href=#fail-the-websocket-connection>fail the
+ WebSocket connection</a> and abort these steps.</dd>
+
+
+ <dt>If the entry's name is "<code title=http-sec-websocket-origin><a href=#sec-websocket-origin>sec-websocket-origin</a></code>"</dt>
+
<dd><p>If the value is not exactly equal to <var title="">origin</var>, <a href=#converted-to-ascii-lowercase>converted to ASCII lowercase</a>,
- then <a href=#fail-the-web-socket-connection>fail the Web Socket connection</a> and abort these
+ then <a href=#fail-the-websocket-connection>fail the WebSocket connection</a> and abort these
steps. <a href=#refsORIGIN>[ORIGIN]</a></dd>
- <dt>If the entry's name is "<code title=http-websocket-location><a href=#websocket-location>websocket-location</a></code>"</dt>
+ <dt>If the entry's name is "<code title=http-sec-websocket-location><a href=#sec-websocket-location>sec-websocket-location</a></code>"</dt>
<dd>
<p>If the value is not exactly equal to a string obtained from
- the steps to <a href=#construct-a-web-socket-url>construct a Web Socket URL</a> from <var title="">host</var>, <var title="">port</var>, <var title="">resource name</var>, and the <var title="">secure</var>
- flag, then <a href=#fail-the-web-socket-connection>fail the Web Socket connection</a> and abort
+ the steps to <a href=#construct-a-websocket-url>construct a WebSocket URL</a> from <var title="">host</var>, <var title="">port</var>, <var title="">resource name</var>, and the <var title="">secure</var>
+ flag, then <a href=#fail-the-websocket-connection>fail the WebSocket connection</a> and abort
these steps.</p>
</dd>
- <dt>If the entry's name is "<code title=http-websocket-protocol><a href=#websocket-protocol-0>websocket-protocol</a></code>"</dt>
+ <dt>If the entry's name is "<code title=http-sec-websocket-protocol><a href=#sec-websocket-protocol>sec-websocket-protocol</a></code>"</dt>
<dd><p>If there was a <var title="">protocol</var> specified, and
the value is not exactly equal to <var title="">protocol</var>,
- then <a href=#fail-the-web-socket-connection>fail the Web Socket connection</a> and abort these
+ then <a href=#fail-the-websocket-connection>fail the WebSocket connection</a> and abort these
steps. (If no <var title="">protocol</var> was specified, the
- header is ignored.)</dd>
+ field is ignored.)</dd>
<dt>If the entry's name is "<code title=http-setcookie>set-cookie</code>" or "<code title=http-setcookie2>set-cookie2</code>" or another
- cookie-related header name</dt>
+ cookie-related field name</dt>
<dd><p>Handle the cookie as defined by the appropriate
specification, with the resource being the one with the host <var title="">host</var>, the port <var title="">port</var>, the path
@@ -68152,10 +68386,10 @@
<p>If <var title="">mode</var> is <i title="">redirect</i>, then:
If there is not exactly one entry in the <var
- title="">headers</var> list whose name is "<code
- title="">location</code>", then <span>fail the Web Socket
+ title="">fields</var> list whose name is "<code
+ title="">location</code>", then <span>fail the WebSocket
connection</span> and abort these steps. Otherwise, handle each
- entry in the <var title="">headers</var> list as follows:</p>
+ entry in the <var title="">fields</var> list as follows:</p>
<dl class="switch">
@@ -68169,20 +68403,20 @@
<li><p>Let <var title="">was secure</var> have the value of
<var title="">secure</var>.</p></li>
- <li><p><span>Parse a Web Socket URL's components</span> from
+ <li><p><span>Parse a WebSocket URL's components</span> from
the <var title="">url</var> argument, to obtain new values for
<var title="">host</var>, <var title="">port</var>, <var
title="">resource name</var>, and <var
- title="">secure</var>. If this fails, <span>fail the Web Socket
+ title="">secure</var>. If this fails, <span>fail the WebSocket
connection</span> and abort these steps.</p></li>
<li><p>If <var title="">was secure</var> is true but <var
- title="">secure</var> is now false, <span>fail the Web Socket
+ title="">secure</var> is now false, <span>fail the WebSocket
connection</span> and abort these steps.</p></li>
<li><p>If <var title="">port</var> is a port to which the user
- agent is configured to block access, then <span>fail the Web
- Socket connection</span> and abort these steps. (User agents
+ agent is configured to block access, then <span>fail the
+ WebSocket connection</span> and abort these steps. (User agents
typically block access to well-known ports like SMTP.)</p></li>
<li><p>Close the connection if the server has not already done
@@ -68206,10 +68440,10 @@
<p>If <var title="">mode</var> is <i title="">authenticate</i>,
then: If there is not exactly one entry in the <var
- title="">headers</var> list whose name is "<code
- title="">www-authenticate</code>", then <span>fail the Web Socket
+ title="">fields</var> list whose name is "<code
+ title="">www-authenticate</code>", then <span>fail the WebSocket
connection</span> and abort these steps. Otherwise, handle each
- entry in the <var title="">headers</var> list as follows:</p>
+ entry in the <var title="">fields</var> list as follows:</p>
<dl class="switch">
@@ -68235,7 +68469,56 @@
<li>
- <p>The <dfn id=web-socket-connection-is-established>Web Socket connection is established</dfn>. Now the
+ <p>Let <var title="">challenge</var> be the concatenation of <var title="">number<sub>1</sub></var>, expressed as a little-endian 32
+ bit integer, <var title="">number<sub>2</sub></var>, expressed as
+ a little-endian 32 bit integer, and the eight bytes of <var title="">key<sub>3</sub></var> in the order they were sent on the
+ wire.</p>
+
+ <!--
+ perl -e 'foreach (@ARGV) { print pack 'N', $_ }' 777007543 114997259 | hexdump -C
+ -->
+
+ <p class=example>Using the examples given earlier, this leads to
+ the 16 bytes 0x2E 0x50 0x31 0xB7 0x06 0xDA 0xB8 0x0B 0x47 0x30
+ 0x22 0x2D 0x5A 0x3F 0x47 0x58.</p>
+
+ </li>
+
+ <li>
+
+ <p>Let <var title="">expected</var> be the MD5 fingerprint of <var title="">challenge</var> as a little-endian 128 bit string. <a href=#refsRFC1321>[RFC1321]</a></p>
+
+ <!--
+ perl -e "print pack 'c*', map { hex } @ARGV" 0x2E 0x50 0x31 0xB7 0x06 0xDA 0xB8 0x0B 0x47 0x30 0x22 0x2D 0x5A 0x3F 0x47 0x58 | md5sum -b
+ -->
+
+ <p class=example>Using the examples given earlier, this leads to
+ the 16 bytes 0x30 0x73 0x74 0x33 0x52 0x6C 0x26 0x71 0x2D 0x32
+ 0x5A 0x55 0x5E 0x77 0x65 0x75. In ASCII, these bytes correspond to
+ the string "0st3Rl&q-2ZU^weu".</p>
+
+ </li>
+
+ <li>
+
+ <p>Read sixteen bytes from the server. Let <var title="">reply</var> be those bytes.</p>
+
+ <p>If the connection closes before these bytes are received, then
+ <a href=#fail-the-websocket-connection>fail the WebSocket connection</a> and abort these
+ steps.</p>
+
+ </li>
+
+ <li>
+
+ <p>If <var title="">reply</var> does not exactly equal <var title="">expected</var>, then <a href=#fail-the-websocket-connection>fail the WebSocket
+ connection</a> and abort these steps.</p>
+
+ </li>
+
+ <li>
+
+ <p>The <dfn id=websocket-connection-is-established>WebSocket connection is established</dfn>. Now the
user agent must send and receive to and from the connection as
described in the next section.</p>
@@ -68243,7 +68526,7 @@
</ol><h6 id=data-framing><span class=secno>10.3.4.3.2 </span>Data framing</h6>
- <p>Once a <a href=#web-socket-connection-is-established>Web Socket connection is established</a>, the
+ <p>Once a <a href=#websocket-connection-is-established>WebSocket connection is established</a>, the
user agent must run through the following state machine for the
bytes sent by the server.</p>
@@ -68252,7 +68535,7 @@
<p>Try to read a byte from the server. Let <var title="">frame
type</var> be that byte.</p>
- <p>If no byte could be read because the <a href=#web-socket-connection-is-closed>Web Socket
+ <p>If no byte could be read because the <a href=#websocket-connection-is-closed>WebSocket
connection is closed</a>, then abort.</p>
</li>
@@ -68267,7 +68550,7 @@
<dd>
<p>Run these steps. If at any point during these steps a read is
- attempted but fails because the <a href=#web-socket-connection-is-closed>Web Socket connection is
+ attempted but fails because the <a href=#websocket-connection-is-closed>WebSocket connection is
closed</a>, then abort.</p>
<ol><li><p>Let <var title="">length</var> be zero.</li>
@@ -68299,7 +68582,7 @@
<dd>
<p>Run these steps. If at any point during these steps a read is
- attempted but fails because the <a href=#web-socket-connection-is-closed>Web Socket connection is
+ attempted but fails because the <a href=#websocket-connection-is-closed>WebSocket connection is
closed</a>, then abort.</p>
<ol><li><p>Let <var title="">raw data</var> be an empty byte array.</li>
@@ -68312,8 +68595,8 @@
<li><p>Interpret <var title="">raw data</var> as a UTF-8
string, and store that string in <var title="">data</var>.</p>
- <li><p>If <var title="">frame type</var> is 0x00, then <dfn id=a-message-has-been-received>a
- message has been received</dfn> with text <var title="">data</var>. Otherwise, discard the data.</li>
+ <li><p>If <var title="">frame type</var> is 0x00, then <dfn id=a-websocket-message-has-been-received>a
+ WebSocket message has been received</dfn> with text <var title="">data</var>. Otherwise, discard the data.</li>
</ol></dd>
@@ -68324,11 +68607,11 @@
</ol><p>If the user agent is faced with content that is too large to be
handled appropriately, runs out of resources for buffering incoming
data, or hits an artificial resource limit intended to avoid
- resource starvation, then it must <a href=#fail-the-web-socket-connection>fail the Web Socket
+ resource starvation, then it must <a href=#fail-the-websocket-connection>fail the WebSocket
connection</a>.</p>
- <hr><p>Once a <a href=#web-socket-connection-is-established>Web Socket connection is established</a>, the
- user agent must use the following steps to <dfn id=send-data-using-the-web-socket>send <var title="">data</var> using the Web Socket</dfn>:</p>
+ <hr><p>Once a <a href=#websocket-connection-is-established>WebSocket connection is established</a>, the
+ user agent must use the following steps to <dfn id=send-data-using-the-websocket>send <var title="">data</var> using the WebSocket</dfn>:</p>
<ol><li><p>Send a 0x00 byte to the server.</li>
@@ -68338,7 +68621,7 @@
<li><p>Send a 0xFF byte to the server.</li>
</ol><p>If at any point there is a fatal problem with sending data to the
- server, the user agent must <a href=#fail-the-web-socket-connection>fail the Web Socket
+ server, the user agent must <a href=#fail-the-websocket-connection>fail the WebSocket
connection</a>.</p>
<!-- v2: People often request the ability to send binary blobs over
@@ -68347,17 +68630,17 @@
data. -->
- <h6 id=closing-the-connection><span class=secno>10.3.4.3.3 </span>Closing the connection</h6>
+ <h6 id=failing-the-connection><span class=secno>10.3.4.3.3 </span>Failing the connection</h6>
- <p>To <dfn id=fail-the-web-socket-connection>fail the Web Socket connection</dfn>, the user agent must
- <a href=#close-the-web-socket-connection>close the Web Socket connection</a>, and may report the
+ <p>To <dfn id=fail-the-websocket-connection>fail the WebSocket connection</dfn>, the user agent must
+ <a href=#close-the-websocket-connection>close the WebSocket connection</a>, and may report the
problem to the user (which would be especially useful for
developers). However, user agents must not convey the failure
information to the script that attempted the connection in a way
- distinguishable from the Web Socket being closed normally.</p>
+ distinguishable from the WebSocket being closed normally.</p>
<p>Except as indicated above or as specified by the application
- layer (e.g. a script using the Web Socket API), user agents should
+ layer (e.g. a script using the WebSocket API), user agents should
not close the connection.</p>
@@ -68373,190 +68656,172 @@
<h5 id=server-side-requirements><span class=secno>10.3.4.4 </span>Server-side requirements</h5>
<p><i>This section only applies to servers.</i></p>
-
- <h6 id="sending-the-server's-handshake"><span class=secno>10.3.4.4.1 </span>Sending the server's handshake</h6>
- <p>When a client establishes a Web Socket connection to a server,
- the server must either close the connection or send the server
- handshake. Servers may read part or all of the client's handshake
- (as described in the next section) before closing the connection or
- sending all of their side of the handshake; indeed, in some cases
- this is necessary as the server might need to use some of the
- information in the client's handshake to construct it's own
- handshake.</p>
+ <h6 id="reading-the-client's-handshake"><span class=secno>10.3.4.4.1 </span>Reading the client's handshake</h6>
- <p>If the server supports encryption, then the server must perform a
- TLS handshake over the connection before sending the server
- handshake. If this fails (e.g. the client indicated a host name in
- the extended client hello "server_name" extension that the server
- does not host), then the server must close the connection;
- otherwise, all further communication for the connection (including
- the server handshake) must run through the encrypted tunnel. <a href=#refsRFC2246>[RFC2246]</a></p>
+ <p>When a client starts a WebSocket connection, it sends its part of
+ the handshake. The server must parse at least part of this handshake
+ in order to obtain the necessary information to generate the server
+ part of the handshake.</p>
- <p>To send the server handshake, the server must first establish the
- following information:</p>
+ <p>The client handshake consists of the following parts. If the
+ server, while reading the handshake, finds that the client did not
+ send a handshake that matches the description below, the server
+ should <a href=#abort-the-websocket-connection>abort the WebSocket connection</a>.</p>
- <dl><dt><var title="">origin</var></dt>
+ <ol><li><p>The three-character UTF-8 string "GET".</li>
- <dd>The <a href=#ascii-serialization-of-an-origin title="ASCII serialization of an origin">ASCII
- serialization</a> of the origin that the server is willing to
- communicate with. If the server can respond to requests from
- multiple origins (or indeed, all origins), then the value should be
- derived from the client's handshake, specifically from the "Origin"
- field. <a href=#refsORIGIN>[ORIGIN]</a></dd>
+ <li><p>A UTF-8-encoded U+0020 SPACE character (0x20 byte).</li>
- <dt><var title="">host</var></dt>
+ <li><p>A string consisting of all the bytes up to the next
+ UTF-8-encoded U+0020 SPACE character (0x20 byte). The result of
+ decoding this string as a UTF-8 string is the name of the resource
+ requested by the server. If the server only supports one resource,
+ then this can safely be ignored; the client verifies that the right
+ resource is supported based on the information included in the
+ server's own handshake. The resource name will begin with U+002F
+ SOLIDUS character (/) and will only include characters in the range
+ U+0021 to U+007E.</li>
- <dd>The host name or IP address of the Web Socket server, as it is
- to be addressed by clients. The host name must be punycode-encoded
- if necessary. If the server can respond to requests to multiple
- hosts (e.g. in a virtual hosting environment), then the value
- should be derived from the client's handshake, specifically from
- the "Host" field.</dd>
+ <li><p>A string of bytes terminated by a UTF-8-encoded U+000D
+ CARRIAGE RETURN U+000A LINE FEED character pair (CRLF). All the
+ characters from the second 0x20 byte up to the first 0x0D 0x0A byte
+ pair in the data from the client can be safely ignored. (It will
+ probably be the string "HTTP/1.1".)</p>
- <dt><var title="">port</var></dt>
+ <li>
- <dd>The port number on which the server expected and/or received
- the connection.</dd>
+ <p>A series of fields.</p>
- <dt><var title="">resource name</var></dt>
+ <p>Each field is terminated by a UTF-8-encoded U+000D CARRIAGE
+ RETURN U+000A LINE FEED character pair (CRLF). The end of the
+ fields is denoted by the terminating CRLF pair being followed
+ immediately by another CRLF pair.</p>
- <dd>An identifier for the service provided by the server. If the
- server provides multiple services, then the value should be derived
- from the client's handshake, specifically from the "Host"
- field.</dd>
+ <p class=note>In other words, the fields start with the first
+ 0x0D 0x0A byte pair and end with the first 0x0D 0x0A 0x0D 0x0A
+ byte sequence.</p>
- <dt><var title="">secure flag</var><dt>
+ <p>The fields are encoded as UTF-8.</p>
- </dt><dd>True if the connection is encrypted or if the server expected
- it to be encrypted; false otherwise.</dd>
+ <p>Each field consists of a name, consisting of one or more
+ characters in the range U+0021 to U+007E, followed by a U+003A
+ COLON character (:) and a U+0020 SPACE character, followed by zero
+ or more characters forming the value.</p>
- <dt><var title="">subprotocol</var></dt>
+ <p>The expected field names, the meaning of their corresponding
+ values, and the processing servers are required to apply to those
+ fields, are described below, after the description of the client
+ handshake.</p>
- <dd>Either null, or a string representing the subprotocol the
- server is ready to use. If the server supports multiple
- subprotocols, then the value should be derived from the client's
- handshake, specifically from the "WebSocket-Protocol" field. The
- absence of such a field is equivalent to the null value. The empty
- string is not the same as the null value for these purposes.</dd>
+ </li>
- </dl><p>Having established this information, the server must start the
- handshake. The initial part of the server's handshake is invariant,
- and must consist of the following bytes:</p>
+ <li>
- <pre>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 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 57 65 62 53 6F 63 6B 65 74 2D 4F
-72 69 67 69 6E 3A 20</pre>
+ <p>After the first 0x0D 0x0A 0x0D 0x0A byte sequence, indicating
+ the end of the fields, the client sends eight random bytes. These
+ are used in constructing the server handshake.</p>
- <p>These bytes must be the first bytes sent on the TCP connection by
- the server. They must be followed by the <var title="">origin</var>
- string, encoded as ANSI_X3.4-1968 (US-ASCII), followed by the
- following bytes: <a href=#refsRFC1345>[RFC1345]</a></p>
+ </li>
- <pre>0D 0A 57 65 62 53 6F 63 6B 65 74 2D 4C 6F 63 61
-74 69 6F 6E 3A 20</pre>
+ </ol><p>The expected field names, and the meaning of their corresponding
+ values, are as follows. Field names must be compared in an
+ <a href=#ascii-case-insensitive>ASCII case-insensitive</a> manner.</p>
- <p>The server must then send the string that results from <a href=#construct-a-web-socket-url title="construct a Web Socket URL">constructing a Web Socket
- URL</a> from <var title="">host</var>, <var title="">port</var>,
- <var title="">resource name</var>, and <var title="">secure
- flag</var>, encoded as ANSI_X3.4-1968 (US-ASCII). <a href=#refsRFC1345>[RFC1345]</a></p>
+ <dl><dt><code title=http-upgrade>Upgrade</code></dt>
- <p>If the <var title="">subprotocol</var> is not null, then the
- server must then send the following bytes:</p>
+ <dd>
- <pre>0D 0A 57 65 62 53 6F 63 6B 65 74 2D 50 72 6F 74
-6F 63 6F 6C 3A 20</pre>
+ <p>Invariant part of the handshake. Will always have a value that
+ is an <a href=#ascii-case-insensitive>ASCII case-insensitive</a> match for the string
+ "WebSocket".</p>
- <p>...followed by the <var title="">subprotocol</var> string,
- encoded as ANSI_X3.4-1968 (US-ASCII). <a href=#refsRFC1345>[RFC1345]</a></p>
+ <p>Can be safely ignored, though the server should <a href=#abort-the-websocket-connection>abort the WebSocket
+ connection</a> if this field is absent or has a different
+ value, to avoid vulnerability to cross-protocol attacks.</p>
- <p>Finally, the server must end its side of the handshake by sending
- the four bytes 0x0D 0x0A 0x0D 0x0A to the client.</p>
+ </dd>
+ <dt><code title=http-connection>Connection</code></dt>
- <h6 id="reading-the-client's-handshake"><span class=secno>10.3.4.4.2 </span>Reading the client's handshake</h6>
-
- <p>When a client starts a Web Socket connection, it sends its part
- of the handshake. This consists of a number of fields separated by
- CRLF pairs (bytes 0x0D 0x0A).</p>
-
- <p>The first field consists of three tokens separated by space
- characters (byte 0x20). The first token is the string "GET", the
- middle token is the resource name, and the third is the string
- "HTTP/1.1".</p>
-
- <p>If the first field does not have three tokens, or if the first
- and third tokens aren't the strings given in the previous paragraph,
- or if the second token doesn't begin with U+002F SOLIDUS character
- (/), the server should abort the connection: it either represents an
- errorneous Web Socket client or a connection from a client expecting
- another protocol altogether.</p>
-
- <p>The subsequent fields consist of a string representing a name, a
- colon and a space (bytes 0x3A 0x20), and a string representing a
- value. The possible names, and the meaning of their corresponding
- values, are as follows:</p>
-
- <dl><dt>Upgrade (bytes 55 70 67 72 61 64 65; always the first name-value pair)</dt>
-
<dd>
- <p>Invariant part of the handshake. Will always have a value
- consisting of bytes 57 65 62 53 6F 63 6B 65 74.</p>
+ <p>Invariant part of the handshake. Will always have a value that
+ is an <a href=#ascii-case-insensitive>ASCII case-insensitive</a> match for the string
+ "Upgrade".</p>
- </dd>
+ <p>Can be safely ignored, though the server should <a href=#abort-the-websocket-connection>abort the WebSocket
+ connection</a> if this field is absent or has a different
+ value, to avoid vulnerability to cross-protocol attacks.</p>
- <dt>Connection (bytes 43 6F 6E 6E 65 63 74 69 6F 6E; always the second name-value pair)</dt>
-
- <dd>
-
- <p>Invariant part of the handshake. Will always have a value
- consisting of bytes 55 70 67 72 61 64 65.</p>
-
</dd>
- <dt>Host (bytes 48 6F 73 74; always the third name-value pair)</dt>
+ <dt><code title=http-host>Host</code></dt>
<dd>
<p>The value gives the hostname that the client intended to use
- when opening the Web Socket. It would be of interest in particular
+ when opening the WebSocket. It would be of interest in particular
to virtual hosting environments, where one server might serve
multiple hosts, and might therefore want to return different
- data. The value must be interpreted as UTF-8.</p>
+ data.</p>
+ <p>Can be safely ignored, though the server should <a href=#abort-the-websocket-connection>abort the WebSocket
+ connection</a> if this field is absent or has a value that
+ does not match the server's host name, to avoid vulnerability to
+ cross-protocol attacks and DNS rebinding attacks.</p>
+
</dd>
- <dt>Origin (bytes 4F 72 69 67 69 6E; always the fourth name-value pair)</dt> <!-- http-origin -->
+ <dt><code title=http-origin>Origin</code></dt>
<dd>
<p>The value gives the scheme, hostname, and port (if it's not the
default port for the given scheme) of the page that asked the
- client to open the Web Socket. It would be interesting if the
+ client to open the WebSocket. It would be interesting if the
server's operator had deals with operators of other sites, since
the server could then decide how to respond (or indeed,
<em>whether</em> to respond) based on which site was requesting a
- connection. The value must be interpreted as UTF-8.</p>
+ connection. <a href=#refsORIGIN>[ORIGIN]</a></p>
+ <p>Can be safely ignored, though the server should <a href=#abort-the-websocket-connection>abort the WebSocket
+ connection</a> if this field is absent or has a value that
+ does not match one of the origins the server is expecting to
+ communicate with, to avoid vulnerability to cross-protocol attacks
+ and cross-site scripting attacks.</p>
+
</dd>
- <dt>WebSocket-Protocol (bytes 57 65 62 53 6F 63 6B 65 74 2D 50 72 6F 74 6F 63 6F 6C; optional, if present, will be the fifth name-value pair)</dt> <!-- http-websocket-protocol -->
+ <dt><code title=http-sec-websocket-protocol><a href=#sec-websocket-protocol>Sec-WebSocket-Protocol</a></code></dt>
<dd>
<p>The value gives the name of a subprotocol that the client is
intending to select. It would be interesting if the server
- supports multiple protocols or protocol versions. The value must
- be interpreted as UTF-8.</p>
+ supports multiple protocols or protocol versions.</p>
+ <p>Can be safely ignored, though the server may <a href=#abort-the-websocket-connection>abort the WebSocket
+ connection</a> if the field is absent but the conventions for
+ communicating with the server are such that the field is
+ expected; and the server should <a href=#abort-the-websocket-connection>abort the WebSocket connection</a>
+ if the field has a value that does not match one of the
+ subprotocols that the server supports, to avoid integrity errors
+ once the connection is established.</p>
+
</dd>
+ <dt><code title=http-sec-websocket-key1><a href=#sec-websocket-key1-and-sec-websocket-key2>Sec-WebSocket-Key1</a></code></dt>
+ <dt><code title=http-sec-websocket-key2><a href=#sec-websocket-key1-and-sec-websocket-key2>Sec-WebSocket-Key2</a></code></dt>
+
+ <dd>
+
+ <p>The values provide the information required for computing the
+ server's handshake, as described in the next section.</p>
+
+ </dd>
+
<dt>Other fields</dt>
<dd>
@@ -68572,33 +68837,307 @@
connect (e.g. because they are on an intranet firewalled from the
public Internet), then the server should also verify that the
client's handshake includes the invariant "Upgrade" and
- "Connection" parts of the handshake. Otherwise, an attacker could
- trick a client into sending Web Socket frames to a server
+ "Connection" parts of the handshake, and should send the server's
+ handshake before changing any user data. Otherwise, an attacker
+ could trick a client into sending WebSocket frames to a server
(e.g. using <code>XMLHttpRequest</code>) and cause the server to
perform actions on behalf of the user without the user's
- consent.</p>
+ consent. (Sending the server's handshake ensures that the frames
+ were not sent as part of a cross-protocol attack, since other
+ protocols do not send the necessary components in the client's
+ initial handshake for forming the server's handshake.)</p>
</dd>
- </dl><p>A final field consisting of the empty string (two consecutive
- CRLF pairs) indicates the end of the client's handshake.</p>
+ </dl><p>Unrecognised fields can be safely ignored, and are probably
+ either the result of intermediaries injecting fields unrelated to
+ the operation of the WebSocket protocol, or clients that support
+ future versions of the protocol offering options that the server
+ doesn't support.</p>
- <p>Any fields that lack the colon-space separator must at a minimum
- be discarded and may cause the server to disconnect.</p>
+
+ <h6 id="sending-the-server's-handshake"><span class=secno>10.3.4.4.2 </span>Sending the server's handshake</h6>
- <p>Whether the server does or does not read the client handshake, it
- must at a minimum read (and optionally discard) bytes until it has
- read the first sequence of four bytes 0x0A 0x0D 0x0A 0x0D, which
- signals the end of the client handshake. Servers may do this before
- or after sending their handshake, but must do it before reading
- frames from the client as described in the next section.</p>
+ <p>When a client establishes a WebSocket connection to a server, the
+ server must run the following steps.</p>
+ <ol><li>
+ <p>If the server supports encryption, perform a TLS handshake over
+ the connection. If this fails (e.g. the client indicated a host
+ name in the extended client hello "server_name" extension that the
+ server does not host), then close the connection; otherwise, all
+ further communication for the connection (including the server
+ handshake) must run through the encrypted tunnel. <a href=#refsRFC2246>[RFC2246]</a></p>
+
+ </li>
+
+ <li>
+
+ <p>Establish the following information:</p>
+
+ <dl><dt><var title="">host</var></dt>
+
+ <dd>The host name or IP address of the WebSocket server, as it is
+ to be addressed by clients. The host name must be
+ punycode-encoded if necessary. If the server can respond to
+ requests to multiple hosts (e.g. in a virtual hosting
+ environment), then the value should be derived from the client's
+ handshake, specifically from the "<code title=http-host>Host</code>" field.</dd>
+
+ <dt><var title="">port</var></dt>
+
+ <dd>The port number on which the server expected and/or received
+ the connection.</dd>
+
+ <dt><var title="">resource name</var></dt>
+
+ <dd>An identifier for the service provided by the server. If the
+ server provides multiple services, then the value should be
+ derived from the resource name given in the client's
+ handshake.</dd>
+
+ <dt><var title="">secure flag</var><dt>
+
+ </dt><dd>True if the connection is encrypted or if the server expected
+ it to be encrypted; false otherwise.</dd>
+
+ <dt><var title="">origin</var></dt>
+
+ <dd>The <a href=#ascii-serialization-of-an-origin title="ASCII serialization of an origin">ASCII
+ serialization</a> of the origin that the server is willing to
+ communicate with. If the server can respond to requests from
+ multiple origins (or indeed, all origins), then the value should
+ be derived from the client's handshake, specifically from the
+ "<code title=http-origin>Origin</code>" field. <a href=#refsORIGIN>[ORIGIN]</a></dd>
+
+ <dt><var title="">subprotocol</var></dt>
+
+ <dd>Either null, or a string representing the subprotocol the
+ server is ready to use. If the server supports multiple
+ subprotocols, then the value should be derived from the client's
+ handshake, specifically from the "<code title=http-sec-websocket-protocol><a href=#sec-websocket-protocol>Sec-WebSocket-Protocol</a></code>"
+ field. The absence of such a field is equivalent to the null
+ value. The empty string is not the same as the null value for
+ these purposes.</dd>
+
+ <dt><var title="">key1</var></dt>
+
+ <dd>The value of the "<code title=http-sec-websocket-key1><a href=#sec-websocket-key1-and-sec-websocket-key2>Sec-WebSocket-Key1</a></code>"
+ field in the client's handshake.</dd>
+
+ <dt><var title="">key2</var></dt>
+
+ <dd>The value of the "<code title=http-sec-websocket-key2><a href=#sec-websocket-key1-and-sec-websocket-key2>Sec-WebSocket-Key2</a></code>"
+ field in the client's handshake.</dd>
+
+ <dt><var title="">key3</var></dt>
+
+ <dd>The eight random bytes sent after the first 0x0D 0x0A 0x0D
+ 0x0A sequence in the client's handshake.</dd>
+
+ </dl></li>
+
+ <li>
+
+ <p>Let <var title="">location</var> be the string that results
+ from <a href=#construct-a-websocket-url title="construct a WebSocket URL">constructing a
+ WebSocket URL</a> from <var title="">host</var>, <var title="">port</var>, <var title="">resource name</var>, and <var title="">secure flag</var>.</p>
+
+ </li>
+
+ <li>
+
+ <p>Let <var title="">key1-number</var> be the digits (characters
+ in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9)) in
+ <var title="">key1</var>, interpreted as a base ten integer,
+ ignoring all other characters in <var title="">key1</var>.</p>
+
+ <p>Let <var title="">key2-number</var> be the digits (characters
+ in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9)) in
+ <var title="">key2</var>, interpreted as a base ten integer,
+ ignoring all other characters in <var title="">key2</var>.</p>
+
+ <div class=example>
+
+ <p>For example, assume that the client handshake was:</p>
+
+ <pre>GET / HTTP/1.1
+Connection: Upgrade
+Host: example.com
+Upgrade: WebSocket
+Sec-WebSocket-Key1: 3e6b263 4 17 80
+Origin: http://example.com
+Sec-WebSocket-Key2: 17 9 G`ZD9 2 2b 7X 3 /r90
+
+WjN}|M(6</pre>
+
+ <p>The <var title="">key1-number</var> would be the number
+ 3,626,341,780, and the <var title="">key2-number</var> would be
+ the number 1,799,227,390.</p>
+
+ <p>In this example, incidentally, <var title="">key3</var> is
+ "WjN}|M(6", or 0x57 0x6A 0x4E 0x7D 0x7C 0x4D 0x28 0x36.</p>
+
+ </div>
+
+ </li>
+
+ <li>
+
+ <p>Let <var title="">spaces1</var> be the number of U+0020 SPACE
+ characters in <var title="">key1</var>.</p>
+
+ <p>Let <var title="">spaces2</var> be the number of U+0020 SPACE
+ characters in <var title="">key2</var>.</p>
+
+ <p>If either <var title="">spaces1</var> or <var title="">spaces2</var> is zero, then <a href=#abort-the-websocket-connection>abort the WebSocket
+ connection</a>. This is a symptom of a cross-protocol
+ attack.</p>
+
+ <p class=example>In the example above, <var title="">spaces1</var> would be 4 and <var title="">spaces2</var>
+ would be 10.</p>
+
+ </li>
+
+ <li>
+
+ <p>If <var title="">key1-number</var> is not an integral multiple
+ of <var title="">spaces1</var>, then <a href=#abort-the-websocket-connection>abort the WebSocket
+ connection</a>.</p>
+
+ <p>If <var title="">key2-number</var> is not an integral multiple
+ of <var title="">spaces2</var>, then <a href=#abort-the-websocket-connection>abort the WebSocket
+ connection</a>.</p>
+
+ <p class=note>This can only happen if the client is not a
+ conforming WebSocket client.</p>
+
+ </li>
+
+ <li>
+
+ <p>Let <var title="">part1</var> be <var title="">key1-number</var> divided by <var title="">spaces1</var>.</p>
+
+ <p>Let <var title="">part2</var> be <var title="">key2-number</var> divided by <var title="">spaces2</var>.</p>
+
+ <p class=example>In the example above, <var title="">part1</var>
+ would be 906,585,445 and <var title="">part2</var> would be
+ 179,922,739.</p>
+
+ </li>
+
+ <li>
+
+ <p>Let <var title="">challenge</var> be the concatenation of <var title="">part1</var>, expressed as a little-endian 32 bit integer,
+ <var title="">part2</var>, expressed as a little-endian 32 bit
+ integer, and the eight bytes of <var title="">key3</var> in the
+ order they were sent on the wire.</p>
+
+ <!--
+ perl -e 'foreach (@ARGV) { print pack 'N', $_ }' 906585445 179922739 | hexdump -C
+ -->
+
+ <p class=example>In the example above, this would be the 16
+ bytes 0x36 0x09 0x65 0x65 0x0A 0xB9 0x67 0x33 0x57 0x6A 0x4E 0x7D
+ 0x7C 0x4D 0x28 0x36.</p>
+
+ </li>
+
+ <li>
+
+ <p>Let <var title="">response</var> be the MD5 fingerprint of <var title="">challenge</var> as a little-endian 128 bit string. <a href=#refsRFC1321>[RFC1321]</a></p>
+
+ <!--
+ perl -e "print pack 'c*', map { hex } @ARGV" 0x36 0x09 0x65 0x65 0x0A 0xB9 0x67 0x33 0x57 0x6A 0x4E 0x7D 0x7C 0x4D 0x28 0x36 | md5sum -b
+ -->
+
+ <p class=example>In the example above, this would be the 16
+ bytes 0x6E 0x60 0x39 0x65 0x42 0x6B 0x39 0x7A 0x24 0x52 0x38 0x70
+ 0x4F 0x74 0x56 0x62, or "n`9eBk9z$R8pOtVb" in ASCII.
+
+ </li>
+
+ <li>
+
+ <p>Send the following line, terminated by the two characters
+ U+000D CARRIAGE RETURN and U+000A LINE FEED (CRLF) and encoded as
+ UTF-8, to the client:</p>
+
+ <pre>HTTP/1.1 101 WebSocket Protocol Handshake</pre>
+
+ <p>This line may be sent differently if necessary, but must match
+ the Status-Line production defined in the HTTP specification, with
+ the Status-Code having the value 101.</p>
+
+ </li>
+
+ <li>
+
+ <p>Send the following fields to the client. Each field must be
+ sent as a line consisting of the field name, which must be an
+ <a href=#ascii-case-insensitive>ASCII case-insensitive</a> match for the field name in
+ the list below, followed by a U+003A COLON character (:) and a
+ U+0020 SPACE character, followed by the field value as specified
+ in the list below, followed by the two characters U+000D CARRIAGE
+ RETURN and U+000A LINE FEED (CRLF). The lines must be encoded as
+ UTF-8. The lines may be sent in any order.</p>
+
+ <dl><dt><code title=http-upgrade>Upgrade</code></dt>
+
+ <dd><p>The value must be the string "WebSocket".</dd>
+
+ <dt><code title=http-connection>Connection</code></dt>
+
+ <dd><p>The value must be the string "Upgrade".</dd>
+
+ <dt><code title=http-sec-websocket-location><a href=#sec-websocket-location>Sec-WebSocket-Location</a></code></dt>
+
+ <dd><p>The value must be <var title="">location</var></dd>
+
+ <dt><code title=http-sec-websocket-origin><a href=#sec-websocket-origin>Sec-WebSocket-Origin</a></code></dt>
+
+ <dd><p>The value must be <var title="">origin</var></dd>
+
+ <dt><code title=http-sec-websocket-protocol><a href=#sec-websocket-protocol>Sec-WebSocket-Protocol</a></code></dt>
+
+ <dd>
+
+ <p>This field must be included if <var title="">subprotocol</var> is not null, and must not be included
+ if <var title="">subprotocol</var> is null.</p>
+
+ <p>If included, the value must be <var title="">subprotocol</var></p>
+
+ </dd>
+
+ </dl></li>
+
+ <li>
+
+ <p>Send two bytes 0x0D 0x0A (ASCII CRLF).</p>
+
+ </li>
+
+ <li>
+
+ <p>Send <var title="">response</var>.</p>
+
+ </li>
+
+ </ol><p>This completes the server's handshake. If the server finishes
+ these steps without <a href=#abort-the-websocket-connection title="abort the WebSocket
+ connection">aborting the WebSocket connection</a>, and if the
+ client does not then <a href=#fail-the-connection>fail the connection</a>, then the
+ connection is established and the server may begin and receiving
+ sending data, as described in the next section.</p>
+
+
+
<h6 id=ws-sd-framing><span class=secno>10.3.4.4.3 </span>Data framing</h6>
<p>The server must run through the following steps to process the
bytes sent by the client. If at any point during these steps a read
- is attempted but fails because the <a href=#web-socket-connection-is-closed>Web Socket connection is
+ is attempted but fails because the <a href=#websocket-connection-is-closed>WebSocket connection is
closed</a>, then abort.</p>
<ol><li id=wd-sd-frame><p><i title="">Frame</i>: Read a byte from the
@@ -68665,30 +69204,39 @@
<li><p>Send a 0xFF byte to the client to indicate the end of the
message.</li>
- </ol><h6 id=handling-errors-in-utf-8-0><span class=secno>10.3.4.4.4 </span>Handling errors in UTF-8</h6>
+ </ol><h6 id=aborting-the-connection><span class=secno>10.3.4.4.4 </span>Aborting the connection</h6>
+ <p>To <dfn id=abort-the-websocket-connection>abort the WebSocket connection</dfn> during the
+ handshake, the server must <a href=#close-the-websocket-connection>close the WebSocket
+ connection</a>.</p>
+
+
+ <h6 id=handling-errors-in-utf-8-0><span class=secno>10.3.4.4.5 </span>Handling errors in UTF-8</h6>
+
<p>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, behaviour
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 Web Socket protocol might define specific behavior
+ layered on the WebSocket protocol might define specific behavior
for servers.</p>
- <h5 id=closing-the-connection-0><span class=secno>10.3.4.5 </span>Closing the connection</h5>
+ <h5 id=closing-the-connection><span class=secno>10.3.4.5 </span>Closing the connection</h5>
- <p>To <dfn id=close-the-web-socket-connection>close the Web Socket connection</dfn>, either the user
- agent or the server closes the TCP/IP connection. There is no
+ <p>To <dfn id=close-the-websocket-connection>close the WebSocket connection</dfn>, either the user
+ agent or the server closes the TCP connection. There is no
closing handshake. When a user agent notices that the server has
closed its connection, it must immediately close its side of the
connection also. Whether the user agent or the server closes the
- connection first, it is said that the <dfn id=web-socket-connection-is-closed>Web Socket connection is
+ connection first, it is said that the <dfn id=websocket-connection-is-closed>WebSocket connection is
closed</dfn>.</p>
- <p>Servers may <a href=#close-the-web-socket-connection>close the Web Socket connection</a> whenever
- desired. User agents should not <a href=#close-the-web-socket-connection>close the Web Socket
+ <!-- XXX Close Handshake but NOT for FAILing or ABORTing -->
+
+ <p>Servers may <a href=#close-the-websocket-connection>close the WebSocket connection</a> whenever
+ desired. User agents should not <a href=#close-the-websocket-connection>close the WebSocket
connection</a> arbitrarily.</p>
@@ -68697,7 +69245,7 @@
<p>While this protocol is intended to be used by scripts in Web
pages, it can also be used directly by hosts. Such hosts are acting
- on their own behalf, and can therefore send fake "Origin" headers,
+ on their own behalf, and can therefore send fake "Origin" fields,
misleading the server. Servers should therefore be careful about
assuming that they are talking directly to scripts from known
origins, and must consider that they might be accessed in unexpected
@@ -68709,12 +69257,12 @@
the SQL server, lest the server be susceptible to SQL injection.</p>
<hr><p>Servers that are not intended to process input from any Web page
- but only for certain sites should verify the "Origin" header is an
+ but only for certain sites should verify the "Origin" field is an
origin they expect, and should only respond with the corresponding
- "WebSocket-Origin" if it is an accepted origin. Servers that only
- accept input from one origin can just send back that value in the
- "WebSocket-Origin" header, without bothering to check the client's
- value.</p>
+ "Sec-WebSocket-Origin" if it is an accepted origin. Servers that
+ only accept input from one origin can just send back that value in
+ the "Sec-WebSocket-Origin" field, without bothering to check the
+ client's value.</p>
<hr><p>If at any time a server is faced with data that it does not
understand, or that violates some criteria by which the server
@@ -68734,7 +69282,7 @@
<h6 id=registration-of-ws:-scheme><span class=secno>10.3.4.7.1 </span>Registration of <code title="">ws:</code> scheme</h6>
- <p>A <code title="">ws:</code> URL identifies a Web Socket server
+ <p>A <code title="">ws:</code> URL identifies a WebSocket server
and resource name.</p>
<dl><dt>URI scheme name.</dt>
@@ -68758,7 +69306,7 @@
<dt>URI scheme semantics.</dt>
<dd>The only operation for this scheme is to open a connection
- using the Web Socket protocol.</dd>
+ using the WebSocket protocol.</dd>
<dt>Encoding considerations.</dt>
<dd>
@@ -68778,7 +69326,7 @@
</dd>
<dt>Applications/protocols that use this URI scheme name.</dt>
- <dd>Web Socket protocol.</dd>
+ <dd>WebSocket protocol.</dd>
<dt>Interoperability considerations.</dt>
<dd>None.</dd>
@@ -68797,7 +69345,7 @@
</dl><h6 id=registration-of-wss:-scheme><span class=secno>10.3.4.7.2 </span>Registration of <code title="">wss:</code> scheme</h6>
- <p>A <code title="">wss:</code> URL identifies a Web Socket server
+ <p>A <code title="">wss:</code> URL identifies a WebSocket server
and resource name, and indicates that traffic over that connection
is to be encrypted.</p>
@@ -68821,7 +69369,7 @@
<dt>URI scheme semantics.</dt>
<dd>The only operation for this scheme is to open a connection
- using the Web Socket protocol, encrypted using TLS.</dd>
+ using the WebSocket protocol, encrypted using TLS.</dd>
<dt>Encoding considerations.</dt>
<dd>
@@ -68841,7 +69389,7 @@
</dd>
<dt>Applications/protocols that use this URI scheme name.</dt>
- <dd>Web Socket protocol over TLS.</dd>
+ <dd>WebSocket protocol over TLS.</dd>
<dt>Interoperability considerations.</dt>
<dd>None.</dd>
@@ -68872,17 +69420,59 @@
<dt>References.</dt>
<dd>This document.</dd>
- </dl><h6 id=websocket-origin><span class=secno>10.3.4.7.4 </span><dfn title=http-websocket-origin><code>WebSocket-Origin</code></dfn></h6>
+ </dl><h6 id=sec-websocket-key1-and-sec-websocket-key2><span class=secno>10.3.4.7.4 </span><dfn title=http-sec-websocket-key1><code>Sec-WebSocket-Key1</code></dfn> and <dfn title=http-sec-websocket-key2><code>Sec-WebSocket-Key2</code></dfn></h6>
+ <p>This section describes two header fields for registration in the
+ Permanent Message Header Field Registry. <a href=#refsRFC3864>[RFC3864]</a></p>
+
+ <dl><dt>Header field name</dt>
+ <dd>Sec-WebSocket-Key1</dd>
+ <dt>Applicable protocol</dt>
+ <dd>http</dd>
+ <dt>Status</dt>
+ <dd>reserved; do not use outside WebSocket handshake</dd>
+ <dt>Author/Change controller</dt>
+ <dd>IETF</dd>
+ <dt>Specification document(s)</dt>
+ <dd>
+ This document is the relevant specification.
+ </dd>
+ <dt>Related information</dt>
+ <dd>None.</dd>
+ </dl><dl><dt>Header field name</dt>
+ <dd>Sec-WebSocket-Key2</dd>
+ <dt>Applicable protocol</dt>
+ <dd>http</dd>
+ <dt>Status</dt>
+ <dd>reserved; do not use outside WebSocket handshake</dd>
+ <dt>Author/Change controller</dt>
+ <dd>IETF</dd>
+ <dt>Specification document(s)</dt>
+ <dd>
+ This document is the relevant specification.
+ </dd>
+ <dt>Related information</dt>
+ <dd>None.</dd>
+ </dl><p>The <code title=http-sec-websocket-key1><a href=#sec-websocket-key1-and-sec-websocket-key2>Sec-WebSocket-Key1</a></code> and <code title=http-sec-websocket-key2><a href=#sec-websocket-key1-and-sec-websocket-key2>Sec-WebSocket-Key2</a></code> 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.</p>
+
+
+ <h6 id=sec-websocket-location><span class=secno>10.3.4.7.5 </span><dfn title=http-sec-websocket-location><code>Sec-WebSocket-Location</code></dfn></h6>
+
<p>This section describes a header field for registration in the
Permanent Message Header Field Registry. <a href=#refsRFC3864>[RFC3864]</a></p>
<dl><dt>Header field name</dt>
- <dd>WebSocket-Origin</dd>
+ <dd>Sec-WebSocket-Location</dd>
<dt>Applicable protocol</dt>
<dd>http</dd>
<dt>Status</dt>
- <dd>reserved; do not use outside Web Socket handshake</dd>
+ <dd>reserved; do not use outside WebSocket handshake</dd>
<dt>Author/Change controller</dt>
<dd>IETF</dd>
<dt>Specification document(s)</dt>
@@ -68891,24 +69481,26 @@
</dd>
<dt>Related information</dt>
<dd>None.</dd>
- </dl><p>The <code>WebSocket-Origin</code> header is used in the Web
- Socket handshake. It is sent from the server to the client to
- confirm the <a href=#origin>origin</a> 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.</p>
+ </dl><p>The <code title=http-sec-websocket-location><a href=#sec-websocket-location>Sec-WebSocket-Location</a></code>
+ header is used in the WebSocket handshake. It is sent from the
+ server to the client to confirm the <a href=#url>URL</a> 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.</p>
- <h6 id=websocket-protocol-0><span class=secno>10.3.4.7.5 </span><dfn title=http-websocket-protocol><code>WebSocket-Protocol</code></dfn></h6>
+ <h6 id=sec-websocket-origin><span class=secno>10.3.4.7.6 </span><dfn title=http-sec-websocket-origin><code>Sec-WebSocket-Origin</code></dfn></h6>
<p>This section describes a header field for registration in the
Permanent Message Header Field Registry. <a href=#refsRFC3864>[RFC3864]</a></p>
<dl><dt>Header field name</dt>
- <dd>WebSocket-Protocol</dd>
+ <dd>Sec-WebSocket-Origin</dd>
<dt>Applicable protocol</dt>
<dd>http</dd>
<dt>Status</dt>
- <dd>reserved; do not use outside Web Socket handshake</dd>
+ <dd>reserved; do not use outside WebSocket handshake</dd>
<dt>Author/Change controller</dt>
<dd>IETF</dd>
<dt>Specification document(s)</dt>
@@ -68917,24 +69509,25 @@
</dd>
<dt>Related information</dt>
<dd>None.</dd>
- </dl><p>The <code>WebSocket-Protocol</code> header is used in the Web
- Socket 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.</p>
+ </dl><p>The <code title=http-sec-websocket-origin><a href=#sec-websocket-origin>Sec-WebSocket-Origin</a></code> header
+ is used in the WebSocket handshake. It is sent from the server to
+ the client to confirm the <a href=#origin>origin</a> 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.</p>
- <h6 id=websocket-location><span class=secno>10.3.4.7.6 </span><dfn title=http-websocket-location><code>WebSocket-Location</code></dfn></h6>
+ <h6 id=sec-websocket-protocol><span class=secno>10.3.4.7.7 </span><dfn title=http-sec-websocket-protocol><code>Sec-WebSocket-Protocol</code></dfn></h6>
<p>This section describes a header field for registration in the
Permanent Message Header Field Registry. <a href=#refsRFC3864>[RFC3864]</a></p>
<dl><dt>Header field name</dt>
- <dd>WebSocket-Location</dd>
+ <dd>Sec-WebSocket-Protocol</dd>
<dt>Applicable protocol</dt>
<dd>http</dd>
<dt>Status</dt>
- <dd>reserved; do not use outside Web Socket handshake</dd>
+ <dd>reserved; do not use outside WebSocket handshake</dd>
<dt>Author/Change controller</dt>
<dd>IETF</dd>
<dt>Specification document(s)</dt>
@@ -68943,24 +69536,24 @@
</dd>
<dt>Related information</dt>
<dd>None.</dd>
- </dl><p>The <code>WebSocket-Location</code> header is used in the Web
- Socket handshake. It is sent from the server to the client to
- confirm the <a href=#url>URL</a> 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.</p>
+ </dl><p>The <code title=http-sec-websocket-protocol><a href=#sec-websocket-protocol>Sec-WebSocket-Protocol</a></code>
+ 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.</p>
- <h5 id=using-the-web-socket-protocol-from-other-specifications><span class=secno>10.3.4.8 </span>Using the Web Socket protocol from other specifications</h5>
+ <h5 id=using-the-websocket-protocol-from-other-specifications><span class=secno>10.3.4.8 </span>Using the WebSocket protocol from other specifications</h5>
- <p>The Web Socket protocol is intended to be used by another
+ <p>The WebSocket protocol is intended to be used by another
specification to provide a generic mechanism for dynamic
author-defined content, e.g. in a specification defining a scripted
API.</p>
- <p>Such a specification first needs to "<a href=#establish-a-web-socket-connection>establish a Web Socket
+ <p>Such a specification first needs to "<a href=#establish-a-websocket-connection>establish a WebSocket
connection</a>", providing that algorithm with:</p>
<ul><li>The destination, consisting of a <var title="">host</var> and a
@@ -68976,31 +69569,31 @@
made responsible for the connection. <a href=#refsORIGIN>[ORIGIN]</a></li>
<li>Optionally a string identifying a <span>protocol</span> that is
- to be layered over the Web Socket connection.</li>
+ to be layered over the WebSocket connection.</li>
</ul><p>The <var title="">host</var>, <var title="">port</var>, <var title="">resource name</var>, and <var title="">secure</var> flag
are usually obtained from a <a href=#url>URL</a> using the steps to
- <a href="#parse-a-web-socket-url's-components">parse a Web Socket URL's components</a>. These steps fail
- if the URL does not specify a Web Socket.</p>
+ <a href="#parse-a-websocket-url's-components">parse a WebSocket URL's components</a>. These steps fail
+ if the URL does not specify a WebSocket.</p>
<p>If a connection can be established, then it is said that the
- "<a href=#web-socket-connection-is-established>Web Socket connection is established</a>".</p>
+ "<a href=#websocket-connection-is-established>WebSocket connection is established</a>".</p>
<p>If at any time the connection is to be closed, then the
- specification needs to use the "<a href=#close-the-web-socket-connection>close the Web Socket
+ specification needs to use the "<a href=#close-the-websocket-connection>close the WebSocket
connection</a>" algorithm.</p>
<p>When the connection is closed, for any reason including failure
to establish the connection in the first place, it is said that the
- "<a href=#web-socket-connection-is-closed>Web Socket connection is closed</a>".</p>
+ "<a href=#websocket-connection-is-closed>WebSocket connection is closed</a>".</p>
<p>While a connection is open, the specification will need to handle
- the cases when "<span>a Web Socket message has been received</span>"
+ the cases when "<a href=#a-websocket-message-has-been-received>a WebSocket message has been received</a>"
with text <var title="">data</var>.</p>
<p>To send some text <var title="">data</var> to an open connection,
- the specification needs to "<a href=#send-data-using-the-web-socket>send <var title="">data</var>
- using the Web Socket</a>".</p>
+ the specification needs to "<a href=#send-data-using-the-websocket>send <var title="">data</var>
+ using the WebSocket</a>".</p>
@@ -89106,6 +89699,10 @@
Names - Concepts and Facilities</a></cite>, P. Mockapetris. IETF,
November 1987.</dd>
+ <dt id=refsRFC1321>[RFC1321]</dt>
+ <dd><cite><a href=http://www.ietf.org/rfc/rfc1321.txt>The MD5
+ Message-Digest Algorithm</a></cite>, R. Rivest. IETF.</dd>
+
<dt id=refsRFC1345>[RFC1345]</dt>
<dd><cite><a href=http://www.ietf.org/rfc/rfc1345.txt>Character Mnemonics
and Character Sets</a></cite>, K. Simonsen. IETF.</dd>
Modified: index
===================================================================
--- index 2010-02-25 10:55:53 UTC (rev 4813)
+++ index 2010-03-02 09:01:43 UTC (rev 4814)
@@ -161,7 +161,7 @@
<header class=head id=head><p><a class=logo href=http://www.whatwg.org/ rel=home><img alt=WHATWG src=/images/logo></a></p>
<hgroup><h1>HTML5 (including next generation additions still in development)</h1>
- <h2 class="no-num no-toc">Draft Standard — 25 February 2010</h2>
+ <h2 class="no-num no-toc">Draft Standard — 2 March 2010</h2>
</hgroup><p>You can take part in this work. <a href=http://www.whatwg.org/mailing-list>Join the working group's discussion list.</a></p>
<p><strong>Web designers!</strong> We have a <a href=http://blog.whatwg.org/faq/>FAQ</a>, a <a href=http://forums.whatwg.org/>forum</a>, and a <a href=http://www.whatwg.org/mailing-list#help>help mailing list</a> for you!</p>
<!--<p class="impl"><strong>Implementors!</strong> We have a <a href="http://www.whatwg.org/mailing-list#implementors">mailing list</a> for you too!</p>-->
@@ -1195,10 +1195,10 @@
<ul class=brief><li><a href=http://www.whatwg.org/specs/web-workers/current-work/>Web Workers</a>
<li><a href=http://dev.w3.org/html5/webstorage/>Web Storage</a>
- <li><a href=http://dev.w3.org/html5/websockets/>Web Sockets API</a>
- <li><a href=http://www.whatwg.org/specs/web-socket-protocol/>Web Sockets protocol</a>
+ <li><a href=http://dev.w3.org/html5/websockets/>WebSocket API</a>
+ <li><a href=http://www.whatwg.org/specs/web-socket-protocol/>WebSocket protocol</a>
<!--
- <li><a href="http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol">Web Sockets protocol</a>
+ <li><a href="http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol">WebSocket protocol</a>
-->
<li><a href=http://dev.w3.org/html5/eventsource/>Server-sent Events</a>
<li><a href=http://dev.w3.org/html5/webdatabase/>Web SQL Database</a>
@@ -38353,16 +38353,16 @@
character not followed by a U+000A LINE FEED (LF) character, and
every occurrence of a U+000A LINE FEED (LF) character not preceded
by a U+000D CARRIAGE RETURN (CR) character, by a two-character
- string consisting of a U+000D CARRIAGE RETURN - U+000A LINE FEED
+ string consisting of a U+000D CARRIAGE RETURN U+000A LINE FEED
(CRLF) character pair.</li>
<li><p>If the element's <code title=attr-textarea-wrap><a href=#attr-textarea-wrap>wrap</a></code> attribute is in the <a href=#attr-textarea-wrap-hard-state title=attr-textarea-wrap-hard-state>Hard</a> state, insert
- U+000D CARRIAGE RETURN - U+000A LINE FEED (CRLF) character pairs
+ U+000D CARRIAGE RETURN U+000A LINE FEED (CRLF) character pairs
into the string using a UA-defined algorithm so that each line has
no more than <a href=#attr-textarea-cols-value title=attr-textarea-cols-value>character
width</a> characters. For the purposes of this requirement,
lines are delimited by the start of the string, the end of the
- string, and U+000D CARRIAGE RETURN - U+000A LINE FEED (CRLF)
+ string, and U+000D CARRIAGE RETURN U+000A LINE FEED (CRLF)
character pairs.</li>
</ol></div>
@@ -55557,7 +55557,7 @@
<code><a href=#document>Document</a></code>'s <var title=concept-document-salvageable>salvageable</var> state to
false. <a href=#refsWEBSQL>[WEBSQL]</a> </li>
- <li><p><span>Close the Web Socket connection</span> of any
+ <li><p><span>Close the WebSocket connection</span> of any
<code>WebSocket</code> objects that were created by the <code title=dom-WebSocket>WebSocket()</code> constructor visible on the
<code><a href=#document>Document</a></code>'s <code><a href=#window>Window</a></code> object. If this
affected any <code>WebSocket</code> objects, the set
@@ -83792,10 +83792,10 @@
<dt id=refsWEBSOCKET>[WEBSOCKET]</dt>
<!--
- <dd><cite><a href="http://www.w3.org/TR/websockets/">The Web Sockets
+ <dd><cite><a href="http://www.w3.org/TR/websockets/">The WebSocket
API</a></cite>, I. Hickson. W3C.</dd>
-->
- <dd><cite><a href=http://dev.w3.org/html5/websockets/>The Web Sockets
+ <dd><cite><a href=http://dev.w3.org/html5/websockets/>The WebSocket
API</a></cite>, I. Hickson. W3C.</dd>
<dt id=refsWEBSQL>[WEBSQL]</dt>
Modified: source
===================================================================
--- source 2010-02-25 10:55:53 UTC (rev 4813)
+++ source 2010-03-02 09:01:43 UTC (rev 4814)
@@ -71,10 +71,10 @@
<ul class="brief">
<li><a href="http://www.whatwg.org/specs/web-workers/current-work/">Web Workers</a>
<li><a href="http://dev.w3.org/html5/webstorage/">Web Storage</a>
- <li><a href="http://dev.w3.org/html5/websockets/">Web Sockets API</a>
- <li><a href="http://www.whatwg.org/specs/web-socket-protocol/">Web Sockets protocol</a>
+ <li><a href="http://dev.w3.org/html5/websockets/">WebSocket API</a>
+ <li><a href="http://www.whatwg.org/specs/web-socket-protocol/">WebSocket protocol</a>
<!--
- <li><a href="http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol">Web Sockets protocol</a>
+ <li><a href="http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol">WebSocket protocol</a>
-->
<li><a href="http://dev.w3.org/html5/eventsource/">Server-sent Events</a>
<li><a href="http://dev.w3.org/html5/webdatabase/">Web SQL Database</a>
@@ -42805,18 +42805,18 @@
character not followed by a U+000A LINE FEED (LF) character, and
every occurrence of a U+000A LINE FEED (LF) character not preceded
by a U+000D CARRIAGE RETURN (CR) character, by a two-character
- string consisting of a U+000D CARRIAGE RETURN - U+000A LINE FEED
+ string consisting of a U+000D CARRIAGE RETURN U+000A LINE FEED
(CRLF) character pair.</p></li>
<li><p>If the element's <code
title="attr-textarea-wrap">wrap</code> attribute is in the <span
title="attr-textarea-wrap-hard-state">Hard</span> state, insert
- U+000D CARRIAGE RETURN - U+000A LINE FEED (CRLF) character pairs
+ U+000D CARRIAGE RETURN U+000A LINE FEED (CRLF) character pairs
into the string using a UA-defined algorithm so that each line has
no more than <span title="attr-textarea-cols-value">character
width</span> characters. For the purposes of this requirement,
lines are delimited by the start of the string, the end of the
- string, and U+000D CARRIAGE RETURN - U+000A LINE FEED (CRLF)
+ string, and U+000D CARRIAGE RETURN U+000A LINE FEED (CRLF)
character pairs.</p></li>
</ol>
@@ -62761,7 +62761,7 @@
title="concept-document-salvageable">salvageable</var> state to
false. <a href="#refsWEBSQL">[WEBSQL]</a> </p></li>
- <li><p><span>Close the Web Socket connection</span> of any
+ <li><p><span>Close the WebSocket connection</span> of any
<code>WebSocket</code> objects that were created by the <code
title="dom-WebSocket">WebSocket()</code> constructor visible on the
<code>Document</code>'s <code>Window</code> object. If this
@@ -75263,7 +75263,7 @@
<!-- beware, this is very similar to the steps for what happens
during a redirect, in the protocol section -->
- <li><p><span>Parse a Web Socket URL's components</span> from the
+ <li><p><span>Parse a WebSocket URL's components</span> from the
<var title="">url</var> argument, to obtain <var
title="">host</var>, <var title="">port</var>, <var
title="">resource name</var>, and <var title="">secure</var>. If
@@ -75295,18 +75295,18 @@
<li>
- <p><span>Establish a Web Socket connection</span> to a host <var
+ <p><span>Establish a WebSocket connection</span> to a host <var
title="">host</var>, on port <var title="">port</var> (if one was
specified), from <var title="">origin</var>, with the flag <var
title="">secure</var>, with <var title="">resource name</var> as
the resource name, and with <var title="">protocol</var> as the
protocol (if it is present).</p>
- <p class="note">If the "<span>establish a Web Socket
+ <p class="note">If the "<span>establish a WebSocket
connection</span>" algorithm fails, it triggers the "<span>fail
- the Web Socket connection</span>" algorithm, which then invokes
- the "<span>close the Web Socket connection</span>" algorithm,
- which then establishes that the "<span>Web Socket connection is
+ the WebSocket connection</span>" algorithm, which then invokes
+ the "<span>close the WebSocket connection</span>" algorithm,
+ which then establishes that the "<span>WebSocket connection is
closed</span>", which fires the <code
title="event-close">close</code> event <a
href="#closeWebSocket">as described below</a>.</p>
@@ -75340,7 +75340,7 @@
<dt><dfn title="dom-WebSocket-OPEN"><code>OPEN</code></dfn> (numeric value 1)</dt>
- <dd>The <span>Web Socket connection is established</span> and communication is possible.</dd>
+ <dd>The <span>WebSocket connection is established</span> and communication is possible.</dd>
<dt><dfn title="dom-WebSocket-CLOSED"><code>CLOSED</code></dfn> (numeric value 2)</dt>
@@ -75361,17 +75361,17 @@
title="">data</var> argument has any unpaired surrogates, then it
must raise <code>SYNTAX_ERR</code>. If the connection is
established, and the string has no unpaired surrogates, then the
- user agent must <span>send <var title="">data</var> using the Web
- Socket</span>. If the data cannot be sent, e.g. because it would
+ user agent must <span>send <var title="">data</var> using the
+ WebSocket</span>. If the data cannot be sent, e.g. because it would
need to be buffered but the buffer is full, the user agent must
- <span>close the Web Socket connection</span>. The method must then
+ <span>close the WebSocket connection</span>. The method must then
return true if the connection is still established (and the data was
queued or sent successfully), or false if the connection is closed
(e.g. because the user agent just had a buffer overflow and failed
to send the data).</p>
<p>The <dfn title="dom-WebSocket-close"><code>close()</code></dfn>
- method must <span>close the Web Socket connection</span> or
+ method must <span>close the WebSocket connection</span> or
connection attempt, if any, and change the <code
title="dom-WebSocket-readyState">readyState</code> attribute's value
to <code title="dom-WebSocket-CLOSED">CLOSED</code> (2). If the
@@ -75437,7 +75437,7 @@
<h4>Feedback from the protocol</h4>
- <p>When the <i>Web Socket connection is established</i>, the user
+ <p>When the <i>WebSocket connection is established</i>, the user
agent must <span>queue a task</span> to first change the <code
title="dom-WebSocket-readyState">readyState</code> attribute's value
to <code title="dom-WebSocket-OPEN">OPEN</code> (1), and then
@@ -75445,7 +75445,7 @@
title="event-open">open</code> at the <code>WebSocket</code>
object.</p>
- <p>When <i>a Web Socket message has been received</i> with text <var
+ <p>When <i>a WebSocket message has been received</i> with text <var
title="">data</var>, the user agent must create an event that uses
the <code>MessageEvent</code> interface, with the event name <code
title="event-message">message</code>, which does not bubble, is not
@@ -75457,7 +75457,7 @@
(1), and if so, dispatch the event at the <code>WebSocket</code>
object.</p>
- <p id="closeWebSocket">When the <i>Web Socket connection is
+ <p id="closeWebSocket">When the <i>WebSocket connection is
closed</i>, the user agent must <span>queue a task</span> to first
change the <code title="dom-WebSocket-readyState">readyState</code>
attribute's value to <code
@@ -75472,7 +75472,7 @@
<p>The <span>task source</span> for all <span
title="concept-task">tasks</span> <span title="queue a
- task">queued</span> in this section is the <dfn>Web Socket task
+ task">queued</span> in this section is the <dfn>WebSocket task
source</dfn>.</p>
@@ -75483,15 +75483,14 @@
<code title="event-message">message</code> events.</p>
<p>If a <code>WebSocket</code> object is garbage collected while its
- connection is still open, the user agent must <span>close the Web
- Socket connection</span>.</p>
+ connection is still open, the user agent must <span>close the WebSocket connection</span>.</p>
<!--END websocket-api-->
<!--START websocket-protocol-->
- <h4 id="websocket-protocol" title="The Web Socket protocol enables
+ <h4 id="websocket-protocol" title="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
@@ -75501,7 +75500,7 @@
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).">The Web Socket protocol</h4>
+ <iframe>s and long polling).">The WebSocket protocol</h4>
<h5>Introduction</h5>
@@ -75533,8 +75532,8 @@
</ul>
<p>A simpler solution would be to use a single TCP connection for
- traffic in both directions. This is what the Web Socket protocol
- provides. Combined with the Web Socket API, it provides an
+ traffic in both directions. This is what the WebSocket protocol
+ provides. Combined with the WebSocket API, it provides an
alternative to HTTP polling for two-way communication from a Web
page to a remote server.
<!--END complete-->
@@ -75559,25 +75558,35 @@
<p>The handshake from the client looks as follows:</p>
<pre>GET /demo HTTP/1.1
+Host: example.com
+Connection: Upgrade
+Sec-WebSocket-Key2: 12998 5 Y3 1 .P00
+Sec-WebSocket-Protocol: sample
Upgrade: WebSocket
-Connection: Upgrade
-Host: example.com
+Sec-WebSocket-Key1: 4 @1 46546xW%0l 1 5
Origin: http://example.com
-WebSocket-Protocol: sample</pre>
+^n:ds[4U</pre>
+
<p>The handshake from the server looks as follows:</p>
- <pre>HTTP/1.1 101 Web Socket Protocol Handshake
+ <pre>HTTP/1.1 101 WebSocket Protocol Handshake
Upgrade: WebSocket
Connection: Upgrade
-WebSocket-Origin: http://example.com
-WebSocket-Location: ws://example.com/demo
-WebSocket-Protocol: sample</pre>
+Sec-WebSocket-Origin: http://example.com
+Sec-WebSocket-Location: ws://example.com/demo
+Sec-WebSocket-Protocol: sample
- <p>The first three lines in each case are hard-coded (the exact case
- and order matters); the remainder are an unordered <span>ASCII
- case-insensitive</span> set of fields, one per line, that match the
- following non-normative ABNF:
+8jKS'y:G*Co,Wxa-</pre>
+
+ <p>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
+ the HTTP specification.</p>
+
+ <p>After the leading line in both cases come an unordered
+ <span>ASCII case-insensitive</span> set of fields, one per line,
+ that each match the following non-normative ABNF:
<!--END complete-->
<a href="#refsRFC5234">[RFC5234]</a>
<!--START complete--><!--END websocket-protocol-->
@@ -75595,12 +75604,21 @@
any-char = %x0000-0009 / %x000B-000C / %x000E-10FFFF
; a Unicode character other than U+000A LINE FEED (LF) or U+000D CARRIAGE RETURN (CR)</pre>
+ <p class="note">The character set for the above ABNF is Unicode. The
+ fields themselves are encoded as UTF-8.</p>
+
<p>Lines that don't match the above production cause the connection
to be aborted.</p>
- <p class="note">The character set for the above ABNF is Unicode. The
- headers themselves are encoded as UTF-8.</p>
+ <p>Finally, after the last field, the client sends 10 bytes
+ starting with 0x0D 0x0A and followed by 8 random bytes, part of a
+ challenge, and the server sends 18 bytes starting with 0x0D 0x0A and
+ followed by 16 bytes consisting of a challenge response. The details
+ of this challenge and other parts of the handshake are described in
+ the next section.</p>
+ <hr>
+
<p>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,
@@ -75610,12 +75628,14 @@
with a 0x00 byte and ends with a 0xFF byte, with the UTF-8 text in
between.</p>
- <p>The Web Socket protocol uses this framing so that specifications
- that use the Web Socket protocol can expose such connections using
+ <p>The WebSocket protocol uses this framing so that specifications
+ that use the WebSocket 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.</p>
+ <!-- XXX Close Handshake -->
+
<p>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
@@ -75638,6 +75658,7 @@
<!--START websocket-protocol-->
</p>
+ <!-- XXX Close Handshake -->
<pre>; the wire protocol as allowed by this specification
frames = *frame
frame = text-frame
@@ -75656,6 +75677,11 @@
<p class="note">The above ABNF is intended for a binary octet
environment.</p>
+ <!-- XXX Close Handshake -->
+ <p class="warning">At this time, the WebSocket protocol cannot be
+ used to send binary data. Using any of the frame types other than
+ 0x00 is invalid.</p>
+
<hr>
<p>The following diagrams summarise the protocol:</p>
@@ -75670,41 +75696,211 @@
`-- (0x80 to 0xFF) --> Length --> Data... ------->-'</pre>
+
+
+ <h6>Handshake</h6>
+
+ <p><i>This section is non-normative.</i></p>
+
+ <p>The handshake is intended to be compatible with HTTP-based
+ server-side software, so that a single port can be used by both HTTP
+ clients talking to that server and WebSocket clients talking to that
+ server. To this end, the WebSocket client's handshake appears to
+ HTTP servers to be a regular GET request with an Upgrade offer:</p>
+
+ <pre>GET /resource HTTP/1.1
+Upgrade: WebSocket
+Connection: Upgrade</pre>
+
+ <p>Additional fields are used to select options in the WebSocket
+ protocol. The only option available in this version is the
+ subprotocol selector, <code
+ title="http-sec-websocket-protocol">Sec-WebSocket-Protocol</code>:</p>
+
+ <pre>Sec-WebSocket-Protocol: chat</pre>
+
+ <p>This field indicates the subprotocol (the application-level
+ protocol layered over the WebSocket protocol) that the client
+ intends to use. The server echoes this field in its handshake to
+ indicate that it supports that subprotocol.</p>
+
+ <p>The remainder of the handshake is all security-related. First,
+ the <code title="http-host">Host</code> field is used to protect
+ against DNS rebinding attacks and to allow multiple domains to be
+ served from one IP address.</p>
+
+ <pre>Host: example.com</pre>
+
+ <p>The server includes the hostname in the <code
+ title="http-sec-websocket-location">Sec-WebSocket-Location</code>
+ field of its handshake, so that both the client and the server can
+ verify that they agree on which host is in use.</p>
+
+ <p>Second, the <code title="http-origin">Origin</code> field is
+ used to protect against unauthorized cross-origin use of a WebSocket
+ server by scripts using the <code>WebSocket</code> API in a Web
+ browser. The server specifies which origin it is willing to receive
+ requests from by including a <code
+ title="http-sec-websocket-origin">Sec-WebSocket-Origin</code> field
+ with that origin. If multiple origins are authorized, the server
+ echoes the value in the <code title="http-origin">Origin</code>
+ field of the client's handshake.</p>
+
+ <pre>Origin: http://example.com</pre>
+
+ <p>Finally, the server has to prove to the client that it received
+ the client's WebSocket handshake, so that the server doesn't accept
+ connections that are not WebSocket connections. This prevents an
+ attacker from tricking a WebSocket server by sending it
+ carefully-crafted packets using <code>XMLHttpRequest</code> or a
+ <code>form</code> submission.</p>
+
+ <p>To prove that the handshake was received, the server has to take
+ three pieces of information and combine them to form a response. The
+ first two pieces of information come from the <code
+ title="http-sec-websocket-key">Sec-WebSocket-Key1</code> and <code
+ title="http-sec-websocket-key">Sec-WebSocket-Key2</code> fields in
+ the client handshake:</p>
+
+ <pre>Sec-WebSocket-Key1: 18x 6]8vM;54 *(5: { U1]8 z [ 8
+Sec-WebSocket-Key2: 1_ tx7X d < nw 334J702) 7]o}` 0</pre>
+
+ <p>For each of these fields, the server has to take the digits from
+ the value to obtain a number (in this case 1868545188 and 1733470270
+ respectively), then divide that number by the number of spaces
+ characters in the value (in this case 12 and 10) to obtain a 32-bit
+ number (155712099 and 173347027). These two resulting numbers are
+ then used in the server handshake, as described below.</p>
+
+ <p>The counting of spaces is intended to make it impossible to
+ smuggle this field into the resource name; making this even harder
+ is the presence of <em>two</em> such fields, and the use of a
+ newline as the only reliable indicator that the end of the key has
+ been reached. The use of random characters interspersed with the
+ spaces and the numbers ensures that the implementor actually looks
+ for spaces and newlines, instead of being treating any character
+ like a space, which would make it again easy to smuggle the fields
+ into the path and trick the server. Finally, <em>dividing</em> by
+ this number of spaces is intended to make sure that even the most
+ naïve of implementations will check for spaces, since if ther
+ server does not verify that there are some spaces, the server will
+ try to divide by zero, which is usually fatal (a correct handshake
+ will always have at least one space).
+
+ <p>The third piece of information is given after the fields, in the
+ last eight bytes of the handshake, expressed here as they would be
+ seen if interpreted as ASCII:</p>
+
+ <pre>Tm[K T2u</pre>
+
+ <p>The concatenation of the number obtained from processing the
+ <code title="http-sec-websocket-key">Sec-WebSocket-Key1</code>
+ field, expressed as a little-endian 32 bit number, the number
+ obtained from processing the <code
+ title="http-sec-websocket-key">Sec-WebSocket-Key2</code> field,
+ again expressed as a little-endian 32 bit number, and finally the
+ eight bytes at the end of the handshake, form a 128 bit string whose
+ MD5 sum is then used by the server to prove that it read the
+ handshake.</p>
+
+ <hr>
+
+ <p>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 (the HTTP version and reason phrase aren't important):</p>
+
+ <pre>HTTP/1.1 101 WebSocket Protocol Handshake</pre>
+
+ <p>The fields follow. Two of the fields are just for compatibility
+ with HTTP:</p>
+
+ <pre>Upgrade: WebSocket
+Connection: Upgrade</pre>
+
+ <p>Two of the fields are part of the security model described
+ above, echoing the origin and stating the exact host, port, resource
+ name, and whether the connection is expected to be encrypted:</p>
+
+ <pre>Sec-WebSocket-Origin: http://example.com
+Sec-WebSocket-Location: ws://example.com/demo</pre>
+
+ <p>These fields are checked by the Web browser when it is acting as
+ a <code>WebSocket</code> client for scripted pages. A server that
+ only handles one origin and only serves one resource can therefore
+ just return hard-coded values and does not need to parse the
+ client's handshake to verify the correctness of the values.</p>
+
+ <p>Option fields can also be included. In this version of the
+ protocol, the only option field is <code
+ title="http-sec-websocket-protocol">Sec-WebSocket-Protocol</code>,
+ which indicates the subprotocol that the server speaks. Web browsers
+ verify that the server included the same value as was specified in
+ the <code>WebSocket</code> constructor, so a server that speaks
+ multiple subprotocols has to make sure it selects one based on the
+ client's handshake and specifies the right one in its handshake.</p>
+
+ <pre>Sec-WebSocket-Protocol: chat</pre>
+
+ <p>After the fields, the server sends the aforementioned MD5 sum, a
+ 16 byte (128 bit) value, shown here as if interpreted as ASCII:</p>
+
+ <pre>fQJ,fN/4F4!~K~MH</pre>
+
+ <p>This value depends on what the client sends, as described
+ above. If it doesn't match what the client is expecting, the client
+ would disconnect.</p>
+
+ <p>Having part of the handshake appear after the fields ensures
+ that both the server and the client verify that the connection is
+ not being interrupted by an HTTP intermediary such as a
+ man-in-the-middle cache or proxy.</p>
+
+
+
<h6>Design philosophy</h6>
<p><i>This section is non-normative.</i></p>
- <p>The Web Socket protocol is designed on the principle that there
+ <p>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 Web Socket by the
+ 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/IP by the application layer (HTTP).</p>
+ of TCP by the application layer (HTTP).</p>
- <p>Conceptually, Web Socket is really just a layer on top of TCP/IP
+ <p>Conceptually, WebSocket is really just a layer on top of TCP
that adds a Web "origin"-based security model for browsers; adds an
addressing and protocol naming mechanism to support multiple
services on one port and multiple host names on one IP address; and
layers a framing mechanism on top of TCP to get back to the IP
packet mechanism that TCP is built on, but without length
- limits. Other than that, it adds nothing. Basically it is intended
- to be as close to just exposing raw TCP/IP to script as possible
+ limits.
+
+ <!-- XXX Close Handshake -->
+
+ 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.</p>
+ <p>The protocol is intended to be extensible; future versions will
+ likely introduce a mechanism to compress data and might support
+ sending binary data.</p>
+
<h6>Security model</h6>
<p><i>This section is non-normative.</i></p>
- <p>The Web Socket protocol uses the origin model used by Web
- browsers to restrict which Web pages can contact a Web Socket server
- when the Web Socket protocol is used from a Web page. Naturally,
- when the Web 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.</p>
+ <p>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 useful, as the client can provide any arbitrary origin
+ string.</p>
<p>This protocol is intended to fail to establish a connection with
servers of pre-existing protocols like SMTP or HTTP, while allowing
@@ -75714,18 +75910,28 @@
the handshake is finished (thus limiting how much the server can be
influenced).</p>
+ <p>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 <code>form</code>
+ 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 <code title="">Sec-</code> cannot
+ be set by an attacker from a Web browser, even when using
+ <code>XMLHttpRequest</code>.</p>
- <h6>Relationship to TCP/IP and HTTP</h6>
+ <h6>Relationship to TCP and HTTP</h6>
+
<p><i>This section is non-normative.</i></p>
- <p>The Web Socket protocol is an independent TCP-based protocol. Its
+ <p>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.</p>
<p>Based on the expert recommendation of the IANA<!-- [IANA #257455]
- -->, the Web Socket protocol by default uses port 80 for regular Web
- Socket connections and port 443 for Web Socket connections tunneled
+ -->, the WebSocket protocol by default uses port 80 for regular WebSocket connections and port 443 for WebSocket connections tunneled
over TLS.</p>
@@ -75733,15 +75939,16 @@
<p><i>This section is non-normative.</i></p>
- <p>There are several options for establishing a Web Socket connection.</p>
+ <p>There are several options for establishing a WebSocket connection.</p>
<p>On the face of it, the simplest method would seem to be to use
- port 80 to get a direct connection to a Web Socket server. Port 80
- traffic, however, will often be intercepted by HTTP proxies, which
- can lead to the connection failing to be established.</p>
+ port 80 to get a direct connection to a WebSocket server. Port 80
+ traffic, however, will often be intercepted by man-in-the-middle
+ HTTP proxies, which can lead to the connection failing to be
+ established.</p>
<p>The most reliable method, therefore, is to use TLS encryption and
- port 443 to connect directly to a Web Socket server. This has the
+ port 443 to connect directly to a WebSocket server. This has the
advantage of being more secure; however, TLS encryption can be
computationally expensive.</p>
@@ -75751,95 +75958,27 @@
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 Web Socket protocol to be deployed. In more
+ 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 Web Socket connections separate from the
+ dedicated set of hosts for WebSocket connections separate from the
HTTP servers is probably easier to manage.</p>
- <h6>Writing a simple Web Socket server</h6>
- <p><i>This section is non-normative.</i></p>
+ <h6>Subprotocols using the WebSocket protocol</h6>
- <p>If the Web Socket protocol is being used to provide a feature for
- a specific site, then the handshake can be hard-coded, and the data
- provided by the client in the handshake can be safely ignored. This
- section describes an implementation strategy for this case.</p>
-
- <p>Listen on a port for TCP/IP. Upon receiving a connection request,
- open a connection and send the following bytes back to the
- client:</p>
-
- <pre>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 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 57 65 62 53 6F 63 6B 65 74 2D 4F
-72 69 67 69 6E 3A 20</pre>
-
- <p>Send the <span title="ASCII serialization of an origin">ASCII
- serialization</span> of the origin from which the server is willing
- to accept connections. <a href="#refsORIGIN">[ORIGIN]</a></p>
-
- <div class="example">
- <p>For example: <code title="">http://example.com</code></p>
- </div>
-
- <p>Continue by sending the following bytes back to the client:</p>
-
- <pre>0D 0A 57 65 62 53 6F 63 6B 65 74 2D 4C 6F 63 61
-74 69 6F 6E 3A 20</pre>
-
- <p>Send the <span>URL</span> of the Web Socket script.</p>
-
- <div class="example">
- <p>For example: <code title="">ws://example.com/demo</code></p>
- </div>
-
- <p>Finish the handshake by sending the four bytes 0x0D 0x0A 0x0D
- 0x0A to the client. Then, read data <em>from</em> the client until
- four bytes 0x0D 0x0A 0x0D 0x0A are read.</p>
-
- <p class="note">User agents will drop the connection after the
- handshake if the origin and URL sent as part of the algorithm above
- 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.</p>
-
- <p>At this point, there are two concerns: receiving frames and
- sending frames.</p>
-
- <p>To receive a frame, read a byte, verify that it is a 0x00 byte,
- then read bytes until you find a 0xFF byte, and interpret all the
- bytes between the 0x00 and 0xFF bytes as a UTF-8 string (the frame
- payload, or message). This process can be repeated as necessary. If
- at any point the first byte of one of these sequences is not 0x00,
- then an error has occurred, and closing the connection is the
- appropriate response.</p>
-
- <p>To send a frame, first send a 0x00 byte, then send the message as
- a UTF-8 string, then send a 0xFF byte. Again, this process can be
- repeated as necessary.</p>
-
- <p>The connection can be closed as desired.</p>
-
-
- <h6>Subprotocols using the Web Socket protocol</h6>
-
<p><i>This section is non-normative.</i></p>
<p>The client can request that the server use a specific subprotocol
by including the <code
- title="http-websocket-protocol">Websocket-Protocol</code> header in
- its handshake. If it is specified, the server needs to include the
- same header and value in its response for the connection to be
- established.</p>
+ title="http-sec-websocket-protocol">Sec-Websocket-Protocol</code>
+ field in its handshake. If it is specified, the server needs to
+ include the same field and value in its response for the connection
+ to be established.</p>
<p>These subprotocol names do not need to be registered, but if a
subprotocol is intended to be implemented by multiple independent
- Web Socket servers, potential clashes with the names of subprotocols
+ WebSocket servers, potential clashes with the names of subprotocols
defined independently can be avoided by using names that contain the
domain name of the subprotocol's originator. For example, if Example
Corporation were to create a Chat subprotocol to be implemented by
@@ -75853,7 +75992,7 @@
<p>Subprotocols can be versioned in backwards-incompatible ways by
changing the subprotocol name, eg. going from "bookings.example.net"
to "bookings.example.net2". These subprotocols would be considered
- completely separate by Web Socket clients. Backwards-compatible
+ completely separate by WebSocket clients. Backwards-compatible
versioning can be implemented by reusing the same subprotocol string
but carefully designing the actual subprotocol to support this kind
of extensibility.</p>
@@ -75872,6 +76011,13 @@
LETTER Z) with the corresponding characters in the range U+0061
to U+007A (i.e. LATIN SMALL LETTER A to LATIN SMALL LETTER Z).</p>
+ <p>Comparing two strings in an <dfn>ASCII case-insensitive</dfn>
+ 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.</p>
+
<p>The term "URL" 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
@@ -75880,16 +76026,16 @@
<!--START complete-->
<p>When an implementation is required to <i>send</i> data as part of
- the Web Socket protocol, the implementation may delay the actual
+ the WebSocket protocol, the implementation may delay the actual
transmission arbitrarily, e.g. buffering data so as to send fewer IP
packets.</p>
- <h5>Web Socket URLs</h5>
+ <h5>WebSocket URLs</h5>
- <h6>Parsing Web Socket URLs</h6>
+ <h6>Parsing WebSocket URLs</h6>
- <p>The steps to <dfn>parse a Web Socket URL's components</dfn> from
+ <p>The steps to <dfn>parse a WebSocket URL's components</dfn> from
a string <var title="">url</var> are as follows. These steps return
either a <var title="">host</var>, a <var title="">port</var>, a
<var title="">resource name</var>, and a <var title="">secure</var>
@@ -75971,9 +76117,9 @@
</ol>
- <h6>Constructing Web Socket URLs</h6>
+ <h6>Constructing WebSocket URLs</h6>
- <p>The steps to <dfn>construct a Web Socket URL</dfn> from a <var
+ <p>The steps to <dfn>construct a WebSocket URL</dfn> from a <var
title="">host</var>, a <var title="">port</var>, a <var
title="">resource name</var>, and a <var title="">secure</var> flag,
are as follows:</p>
@@ -76016,7 +76162,7 @@
<h6>Handshake</h6>
- <p>When the user agent is to <dfn>establish a Web Socket
+ <p>When the user agent is to <dfn>establish a WebSocket
connection</dfn> to a host <var title="">host</var>, on a port <var
title="">port</var>, from an origin whose <span title="ASCII
serialization of an origin">ASCII serialization</span> is <var
@@ -76035,20 +76181,19 @@
<li>
- <p>If the user agent already has a Web Socket connection to the
+ <p>If the user agent already has a WebSocket connection to the
remote host (IP address) identified by <var title="">host</var>,
even if known by another name, wait until that connection has been
- <span title="Web Socket connection is
+ <span title="WebSocket connection is
established">established</span> or for that connection to have
- <span title="fail the Web Socket connection">failed</span>.</p>
+ <span title="fail the WebSocket connection">failed</span>.</p>
<p class="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.</p>
+ denial of service attack by just opening a large number of WebSocket connections to a remote host.</p>
<p class="note">There is no limit to the number of <span
- title="Web Socket connection is established">established</span>
- Web Socket connections a user agent can have with a single remote
+ title="WebSocket connection is established">established</span>
+ WebSocket 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.</p>
@@ -76058,9 +76203,9 @@
<li>
<p><i>Connect</i>: If the user agent is configured to use a proxy
- when using the Web Socket protocol to connect to host <var
+ when using the WebSocket protocol to connect to host <var
title="">host</var> and/or port <var title="">port</var>, then
- connect to that proxy and ask it to open a TCP/IP connection to
+ connect to that proxy and ask it to open a TCP connection to
the host given by <var title="">host</var> and the port given by
<var title="">port</var>.</p>
@@ -76083,13 +76228,13 @@
</div>
<p>Otherwise, if the user agent is not configured to use a proxy,
- then open a TCP/IP connection to the host given by <var
+ then open a TCP connection to the host given by <var
title="">host</var> and the port given by <var
title="">port</var>.</p>
<p class="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
+ 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.</p>
@@ -76098,10 +76243,10 @@
<span>URL</span> to pass the function must be constructed from
<var title="">host</var>, <var title="">port</var>, <var
title="">resource name</var>, and the <var title="">secure</var>
- flag using the steps to <span>construct a Web Socket
+ flag using the steps to <span>construct a WebSocket
URL</span>.</p>
- <p class="note">The Web Socket protocol can be identified in proxy
+ <p class="note">The WebSocket protocol can be identified in proxy
autoconfiguration scripts from the scheme ("<code
title="">ws:</code>" for unencrypted connections and "<code
title="">wss:</code>" for encrypted connections).</p>
@@ -76109,13 +76254,13 @@
</li>
<li><p>If the connection could not be opened, then <span>fail the
- Web Socket connection</span> and abort these steps.</p></li>
+ WebSocket connection</span> and abort these steps.</p></li>
<li>
<p>If <var title="">secure</var> is true, perform a TLS handshake
over the connection. If this fails (e.g. the server's certificate
- could not be verified), then <span>fail the Web Socket
+ could not be verified), then <span>fail the WebSocket
connection</span> and abort these steps. Otherwise, all further
communication on this channel must run through the encrypted
tunnel. <a href="#refsRFC2246">[RFC2246]</a></p>
@@ -76127,94 +76272,88 @@
<li>
- <p>Send the following bytes to the remote side (the server):</p>
+ <p>Send the UTF-8 string "GET" followed by a UTF-8-encoded U+0020
+ SPACE character to the remote side (the server).</p>
- <pre>47 45 54 20</pre>
-
<p>Send the <var title="">resource name</var> value, encoded as
- ANSI_X3.4-1968 (US-ASCII). <a
- href="#refsRFC1345">[RFC1345]</a></p>
+ UTF-8.</p>
- <p>Send the following bytes:</p>
+ <p>Send another UTF-8-encoded U+0020 SPACE character, followed by
+ the UTF-8 string "HTTP/1.1", followed by a UTF-8-encoded U+000D
+ CARRIAGE RETURN U+000A LINE FEED character pair (CRLF).</p>
- <pre>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</pre>
+ </li>
- <p class="note">The string "GET ", the path,
- " HTTP/1.1", CRLF, the string "Upgrade: WebSocket",
- CRLF, and the string "Connection: Upgrade", CRLF.</p>
+ <li>
+ <p>Let <var title="">fields</var> be an empty list of strings.</p>
+
</li>
<li>
- <p>Send the following bytes:</p>
+ <p>Add the string "Upgrade: WebSocket" to <var
+ title="">fields</var>.</p>
- <pre>48 6F 73 74 3A 20</pre>
+ </li>
- <p>Send the <var title="">host</var> value, <span>converted to
- ASCII lowercase</span>, and encoded as ANSI_X3.4-1968
- (US-ASCII). <a href="#refsRFC1345">[RFC1345]</a></p>
+ <li>
- <p>If <var title="">secure</var> is false, and <var
- title="">port</var> is not 80, or if <var title="">secure</var> is
- true, and <var title="">port</var> is not 443, then send an 0x3A
- byte (ASCII :) followed by the value of <var title="">port</var>,
- expressed as a base-ten integer, encoded as ANSI_X3.4-1968
- (US-ASCII). <a href="#refsRFC1345">[RFC1345]</a></p>
+ <p>Add the string "Connection: Upgrade" to <var
+ title="">fields</var>.</p>
- <p>Send the following bytes:</p>
+ </li>
- <pre>0D 0A</pre>
+ <li>
- <p class="note">The string "Host: ", the host, and CRLF.</p>
+ <p>Let <var title="">hostport</var> be an empty string.</p>
</li>
<li>
- <p>Send the following bytes:</p>
+ <p>Append the <var title="">host</var> value, <span>converted to
+ ASCII lowercase</span>, to <var title="">hostport</var>.</p>
- <pre>4F 72 69 67 69 6E 3A 20</pre>
+ </li>
- <p>Send the <var title="">origin</var> value, <span>converted to
- ASCII lowercase</span>, encoded as ANSI_X3.4-1968 (US-ASCII). <a
- href="#refsORIGIN">[ORIGIN]</a> <a
- href="#refsRFC1345">[RFC1345]</a></p>
+ <li>
- <p class="note">The <var title="">origin</var> value is a string
- that was passed to this algorithm.</p>
+ <p>If <var title="">secure</var> is false, and <var
+ title="">port</var> is not 80, or if <var title="">secure</var> is
+ true, and <var title="">port</var> is not 443, then append a
+ U+003A COLON character (:) followed by the value of <var
+ title="">port</var>, expressed as a base-ten integer, to <var
+ title="">hostport</var>.</p>
- <p>Send the following bytes:</p>
+ </li>
- <pre>0D 0A</pre>
+ <li>
- <p class="note">The string "Origin: ", the origin, and CRLF.</p> <!-- http-origin -->
+ <p>Add the string consisting of the concatenation of the string
+ "Host:", a U+0020 SPACE character, and <var
+ title="">hostport</var>, to <var title="">fields</var>.</p>
</li>
<li>
- <p>If there is no <var title="">protocol</var>, then skip this step.</p>
+ <p>Add the string consisting of the concatenation of the string
+ "Origin:", a U+0020 SPACE character, and the <var
+ title="">origin</var> value, <span>converted to ASCII
+ lowercase</span>, to <var title="">fields</var>.</p>
- <p>Otherwise, send the following bytes:</p>
+ </li>
- <pre>57 65 62 53 6F 63 6B 65 74 2D 50 72 6F 74 6F 63
-6F 6C 3A 20</pre>
+ <li>
- <p>Send the <var title="">protocol</var> value, encoded as
- ANSI_X3.4-1968 (US-ASCII). <a
- href="#refsRFC1345">[RFC1345]</a></p>
+ <p>If there is no <var title="">protocol</var>, then skip this step.</p>
- <p>Send the following bytes:</p>
+ <p>Otherwise, add the string consisting of the concatenation of
+ the string "Sec-WebSocket-Protocol:", a U+0020 SPACE character,
+ and the <var title="">protocol</var> value, to <var
+ title="">fields</var>.</p>
- <pre>0d 0a</pre>
-
- <p class="note">The string "WebSocket-Protocol: ", the
- protocol, and CRLF.</p>
-
</li>
<li>
@@ -76224,8 +76363,9 @@
accessed over HTTP, if <var title="">secure</var> is false, or
HTTPS, if it is true, on host <var title="">host</var>, port <var
title="">port</var>, with <var title="">resource name</var> as the
- path (and possibly query parameters), then HTTP headers that would
- be appropriate for that information should be sent at this point.
+ path (and possibly query parameters), then add to <var
+ title="">fields</var> any HTTP headers that would be appropriate
+ for that information.
<!--END complete-->
<a href="#refsRFC2616">[RFC2616]</a>
<a href="#refsRFC2109">[RFC2109]</a>
@@ -76237,22 +76377,17 @@
</p>
<p>This includes "<code>HttpOnly</code>" cookies (cookies with the
- http-only-flag set to true); the Web Socket protocol is not
- considered a non-HTTP API.</p>
+ http-only-flag set to true); the WebSocket protocol is not
+ considered a non-HTTP API for the purpose of cookie
+ processing.</p>
- <p>Each header must be on a line of its own (each ending with a
- CRLF sequence). For the purposes of this step, each header must
- not be split into multiple lines (despite HTTP otherwise allowing
- this with continuation lines).</p>
-
<!--(v2-ws-auth)
<div class="example">
<p>For example, if the server had a username and password that
applied to <code title="">http://example.com/socket</code>, and
- the Web Socket was being opened to <code
- title="">ws://example.com/socket</code>, it could send
- them:</p>
+ the WebSocket was being opened to <code
+ title="">ws://example.com/socket</code>, it could add them:</p>
<pre>Authorization: Basic d2FsbGU6ZXZl</pre>
@@ -76263,122 +76398,234 @@
<li>
- <p>Send the following bytes:</p>
+ <p>Let <var title="">spaces<sub>1</sub></var> be a random integer
+ from 1 to 12 inclusive.</p>
- <pre>0d 0a</pre>
+ <p>Let <var title="">spaces<sub>2</sub></var> be a random integer
+ from 1 to 12 inclusive.</p>
- <p class="note">Just a CRLF (a blank line).</p>
+ <p class="example">For example, 5 and 9.</p>
</li>
<li>
- <p>Read bytes from the server until either the connection closes,
- or a 0x0A byte is read. Let <var title="">header</var> be these
- bytes, including the 0x0A byte.</p>
+ <p>Let <var title="">max<sub>1</sub></var> be the largest integer
+ not greater than 4,294,967,295 divided by <var
+ title="">spaces<sub>1</sub></var>.</p>
- <p>If <var title="">header</var> is not at least two bytes long,
- or if the last two bytes aren't 0x0D and 0x0A respectively, then
- <span>fail the Web Socket connection</span> and abort these
- steps.</p>
+ <p>Let <var title="">max<sub>2</sub></var> be the largest integer
+ not greater than 4,294,967,295 divided by <var
+ title="">spaces<sub>2</sub></var>.</p>
- <p>User agents may apply a timeout to this step, <span title="fail
- the Web Socket connection">failing the Web Socket
- connection</span> if the server does not send back data in a
- suitable time period.</p>
+ <p class="example">Continuing the example, 858,993,459 and 477,218,588.</p>
</li>
<li>
- <p>If <var title="">header</var> consists of 44 bytes that exactly
- match the following, then let <var title="">mode</var> be <i
- title="">normal</i>.</p>
+ <p>Let <var title="">number<sub>1</sub></var> be a random integer
+ from 0 to <var title="">max<sub>1</sub></var> inclusive.</p>
- <pre>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</pre>
+ <p>Let <var title="">number<sub>2</sub></var> be a random integer
+ from 0 to <var title="">max<sub>2</sub></var> inclusive.</p>
- <p class="note">The string
- "HTTP/1.1 101 Web Socket Protocol Handshake"
- followed by a CRLF pair.</p>
+ <p class="example">For example, 777,007,543 and 114,997,259.</p>
- <p class="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.</p> <!-- we might update this as HTTP is updated,
- depending on whether it remains compatible or whatnot -->
+ </li>
- <p>Otherwise, let <var title="">code</var> be the substring of
- <var title="">header</var> that starts 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 <var
- title="">header</var>, then <span>fail the Web Socket
- connection</span> and abort these steps.</p>
+ <li>
-<!--(v2-redirect)
- <p>If <var title="">code</var>, interpreted as ANSI_X3.4-1968
- (US-ASCII), is either "<code title="">301</code>", "<code
- title="">302</code>", "<code title="">303</code>", "<code
- title="">307</code>", then let <var title="">mode</var> be <i
- title="">redirect</i>. <a href="#refsRFC1345">[RFC1345]</a></p>
--->
-<!--(v2-ws-auth)
- <p>If <var title="">code</var>, interpreted as ANSI_X3.4-1968
- (US-ASCII), is "<code title="">401</code>", then let <var
- title="">mode</var> be <i title="">authenticate</i>. <a
- href="#refsRFC1345">[RFC1345]</a></p>
--->
+ <p>Let <var title="">product<sub>1</sub></var> be the result of
+ multiplying <var title="">number<sub>1</sub></var> and <var
+ title="">spaces<sub>1</sub></var> together.</p>
- <p>If <var title="">code</var>, interpreted as ANSI_X3.4-1968
- (US-ASCII), is "<code title="">407</code>", then either close the
- connection and jump back to step 2, providing appropriate
- authentication information, or <span>fail the Web Socket
- connection</span>. 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 <code
- title="http-Proxy-Authenticate">Proxy-Authenticate</code>
- header). <a href="#refsRFC1345">[RFC1345]</a></p>
+ <p>Let <var title="">product<sub>2</sub></var> be the result of
+ multiplying <var title="">number<sub>2</sub></var> and <var
+ title="">spaces<sub>2</sub></var> together.</p>
- <p>Otherwise, <span>fail the Web Socket connection</span> and
- abort these steps.</p>
+ <p class="example">Continuing the example, 3,885,037,715 and
+ 1,034,975,331.</p>
</li>
<li>
- <p>If <var title="">mode</var> is <i title="">normal</i>, then
- read 41 bytes from the server.</p>
+ <p>Let <var title="">key<sub>1</sub></var> be a string consisting
+ of <var title="">product<sub>1</sub></var>, expressed in base ten
+ using the numerals in the range U+0030 DIGIT ZERO (0) to U+0039
+ DIGIT NINE (9).</p>
- <p>If the connection closes before 41 bytes are received, or if
- the 41 bytes aren't exactly equal to the following bytes, then
- <span>fail the Web Socket connection</span> and abort these
- steps.</p>
+ <p>Let <var title="">key<sub>2</sub></var> be a string consisting
+ of <var title="">product<sub>2</sub></var>, expressed in base ten
+ using the numerals in the range U+0030 DIGIT ZERO (0) to U+0039
+ DIGIT NINE (9).</p>
- <pre>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</pre>
+ <p class="example">Continuing the example, "3885037715" and
+ "1034975331".</p>
- <p class="note">The string "Upgrade: WebSocket", CRLF, the
- string "Connection: Upgrade", CRLF.</p>
+ </li>
+ <li>
+
+ <p>Insert <var title="">spaces<sub>1</sub></var> U+0020 SPACE
+ characters into <var title="">key<sub>1</sub></var> at random
+ positions.</p>
+
+ <p>Insert <var title="">spaces<sub>2</sub></var> U+0020 SPACE
+ characters into <var title="">key<sub>2</sub></var> at random
+ positions.</p>
+
+ <p class="example">Continuing the example, this could lead to
+ "388 5037 7 15" and
+ "1 0 3 4 97 53 31".</p>
+
+ </li>
+
+ <li>
+
+ <p>Insert between one and twelve random characters from
+ the ranges U+0021 to U+002F and U+003A to U+007E into <var
+ title="">key<sub>1</sub></var> at random positions.</p>
+
+ <p>Insert between one and twelve random characters from
+ the ranges U+0021 to U+002F and U+003A to U+007E into <var
+ title="">key<sub>2</sub></var> at random positions.</p>
+
+ <p class="note">This corresponds to random printable ASCII
+ characters other than the digits and the U+0020 SPACE
+ character.</p>
+
+ <p class="example">Continuing the example, this could lead to
+ "388P O503D&ul7 {K%gX( %7 15" and
+ "1 N ?|k UT0or 3o 4 I97N 5-S3O 31".</p>
+
+ </li>
+
+ <li>
+
+ <p>Add the string consisting of the concatenation of the string
+ "Sec-WebSocket-Key1:", a U+0020 SPACE character, and the <var
+ title="">key<sub>1</sub></var> value, to <var
+ title="">fields</var>.</p>
+
+ <p>Add the string consisting of the concatenation of the string
+ "Sec-WebSocket-Key2:", a U+0020 SPACE character, and the <var
+ title="">key<sub>2</sub></var> value, to <var
+ title="">fields</var>.</p>
+
+ </li>
+
+ <li>
+
+ <p>For each string in <var title="">fields</var>, in a random
+ order: send the string, encoded as UTF-8, followed by a
+ UTF-8-encoded U+000D CARRIAGE RETURN U+000A LINE FEED character
+ pair (CRLF). It is important that the fields be output in a
+ random order so that servers not depend on the particular order
+ used by any particular client.</p>
+
+ </li>
+
+ <li>
+
+ <p>Send a UTF-8-encoded U+000D CARRIAGE RETURN U+000A LINE FEED
+ character pair (CRLF).</p>
+
+ </li>
+
+ <li>
+
+ <p>Let <var title="">key3</var> be a string consisting of eight
+ random bytes (or equivalently, a random 64 bit integer encoded in
+ little-endian order).</p>
+
+ <p class="example">For example, 0x47 0x30 0x22 0x2D 0x5A 0x3F 0x47
+ 0x58.</p>
+
+ </li>
+
+ <li>
+
+ <p>Send <var title="">key3</var> to the server.</p>
+
+ </li>
+
+ <li>
+
+ <p>Read bytes from the server until either the connection closes,
+ or a 0x0A byte is read. Let <var title="">field</var> be these
+ bytes, including the 0x0A byte.</p>
+
+ <p>If <var title="">field</var> is not at least seven bytes long,
+ or if the last two bytes aren't 0x0D and 0x0A respectively, or if
+ it does not contain at least two 0x20 bytes, then <span>fail the
+ WebSocket connection</span> and abort these steps.</p>
+
<p>User agents may apply a timeout to this step, <span title="fail
- the Web Socket connection">failing the Web Socket
- connection</span> if the server does not respond with the above
- bytes within a suitable time period.</p>
+ the WebSocket connection">failing the WebSocket
+ connection</span> if the server does not send back data in a
+ suitable time period.</p>
-<!--(v2-ws-auth) (v2-redirect)
- <p class="note">This step is skipped if <var title="">mode</var>
- is <i title="">redirect</i> or <i title="">authenticate</i>.</p>
+ </li>
+
+ <li>
+
+ <p>Let <var title="">code</var> be the substring of <var
+ title="">field</var> that starts from the byte after the first
+ 0x20 byte, and ends with the byte before the second 0x20 byte.</p>
+
+ </li>
+
+ <li>
+
+ <p>If <var title="">code</var> is not three bytes long, or if any
+ of the bytes in <var title="">code</var> are not in the range 0x30
+ to 0x39, then <span>fail the WebSocket connection</span> and abort
+ these steps.</p>
+
+ </li>
+
+ <li>
+
+<!--(v2-redirect or v2-ws-auth) - - then change the text below
+ <p>If <var title="">code</var>, interpreted as UTF-8, is "101",
+ then let <var title="">mode</var> be <i title="">normal</i>.</p>
-->
+<!--(v2-redirect)
+ <p>If <var title="">code</var>, interpreted as UTF-8, is either
+ "<code title="">301</code>", "<code title="">302</code>", "<code
+ title="">303</code>", "<code title="">307</code>", then let <var
+ title="">mode</var> be <i title="">redirect</i>.</p>
+-->
+<!--(v2-ws-auth)
+ <p>If <var title="">code</var>, interpreted as UTF-8, is "<code
+ title="">401</code>", then let <var title="">mode</var> be <i
+ title="">authenticate</i>.</p>
+-->
+ <p>If <var title="">code</var>, interpreted as UTF-8, is "101",
+ then move to the next step.</p>
+
+ <p>If <var title="">code</var>, interpreted as UTF-8, is "<code
+ title="">407</code>", then either close the connection and jump
+ back to step 2, providing appropriate authentication information,
+ or <span>fail the WebSocket connection</span>. 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 <code
+ title="http-Proxy-Authenticate">Proxy-Authenticate</code>
+ header).</p>
+
+ <p>Otherwise, <span>fail the WebSocket connection</span> and abort
+ these steps.</p>
+
</li>
- <li><p>Let <var title="">headers</var> be a list of name-value
+ <li><p>Let <var title="">fields</var> be a list of name-value
pairs, initially empty.</p></li>
- <li id="ws-ua-header-loop"><p><i title="">Header</i>: Let <var
+ <li id="ws-ua-field-loop"><p><i title="">Field</i>: Let <var
title="">name</var> and <var title="">value</var> be empty byte
arrays.</p></li>
@@ -76387,7 +76634,7 @@
<p>Read a byte from the server.</p>
<p>If the connection closes before this byte is received, then
- <span>fail the Web Socket connection</span> and abort these
+ <span>fail the WebSocket connection</span> and abort these
steps.</p>
<p>Otherwise, handle the byte as described in the appropriate
@@ -76398,14 +76645,14 @@
<dt>If the byte is 0x0D (ASCII CR)</dt>
<dd>If the <var title="">name</var> byte array is empty, then
- jump to the <a href="#ws-ua-headers-processing">headers
- processing</a> step. Otherwise, <span>fail the Web Socket
+ jump to the <a href="#ws-ua-fields-processing">fields
+ processing</a> step. Otherwise, <span>fail the WebSocket
connection</span> and abort these steps.</dd>
<dt>If the byte is 0x0A (ASCII LF)</dt>
- <dd><span>Fail the Web Socket connection</span> and abort these
+ <dd><span>Fail the WebSocket connection</span> and abort these
steps.</dd>
@@ -76428,7 +76675,7 @@
</dl>
- <p class="note">This reads a header name, terminated by a colon,
+ <p class="note">This reads a field name, terminated by a colon,
converting upper-case ASCII letters to lowercase, and aborting if
a stray CR or LF is found.</p>
@@ -76439,7 +76686,7 @@
<p>Read a byte from the server.</p>
<p>If the connection closes before this byte is received, then
- <span>fail the Web Socket connection</span> and abort these
+ <span>fail the WebSocket connection</span> and abort these
steps.</p>
<p>Otherwise, handle the byte as described in the appropriate
@@ -76469,7 +76716,7 @@
<p>Read a byte from the server.</p>
<p>If the connection closes before this byte is received, then
- <span>fail the Web Socket connection</span> and abort these
+ <span>fail the WebSocket connection</span> and abort these
steps.</p>
<p>Otherwise, handle the byte as described in the appropriate
@@ -76484,7 +76731,7 @@
<dt>If the byte is 0x0A (ASCII LF)</dt>
- <dd><span>Fail the Web Socket connection</span> and abort these
+ <dd><span>Fail the WebSocket connection</span> and abort these
steps.</dd>
@@ -76495,7 +76742,7 @@
</dl>
- <p class="note">This reads a header value, terminated by a
+ <p class="note">This reads a field value, terminated by a
CRLF.</p>
</li>
@@ -76505,17 +76752,16 @@
<p>Read a byte from the server.</p>
<p>If the connection closes before this byte is received, or if
- the byte is not a 0x0A byte (ASCII LF), then <span>fail the Web
- Socket connection</span> and abort these steps.</p>
+ the byte is not a 0x0A byte (ASCII LF), then <span>fail the WebSocket connection</span> and abort these steps.</p>
<p class="note">This skips past the LF byte of the CRLF after the
- header.</p>
+ field.</p>
</li>
<li>
- <p>Append an entry to the <var title="">headers</var> list that
+ <p>Append an entry to the <var title="">fields</var> list that
has the name given by the string obtained by interpreting the <var
title="">name</var> byte array as a UTF-8 byte stream and the
value given by the string obtained by interpreting the <var
@@ -76525,82 +76771,109 @@
<li>
- <p>Return to the "<a href="#ws-ua-header-loop">Header</a>" step
+ <p>Return to the "<a href="#ws-ua-field-loop">Field</a>" step
above.</p>
</li>
- <li id="ws-ua-headers-processing">
+ <li id="ws-ua-fields-processing">
- <p><i>Headers processing</i>: Read a byte from the server.</p>
+ <p><i>Fields processing</i>: Read a byte from the server.</p>
<p>If the connection closes before this byte is received, or if
- the byte is not a 0x0A byte (ASCII LF), then <span>fail the Web
- Socket connection</span> and abort these steps.</p>
+ the byte is not a 0x0A byte (ASCII LF), then <span>fail the WebSocket connection</span> and abort these steps.</p>
<p class="note">This skips past the LF byte of the CRLF after the
- blank line after the headers.</p>
+ blank line after the fields.</p>
</li>
<li>
- <p>If <var title="">mode</var> is <i title="">normal</i>, then: If
- there is not exactly one entry in the <var title="">headers</var>
- list whose name is "<code
- title="http-websocket-origin">websocket-origin</code>", or if
- there is not exactly one entry in the <var title="">headers</var>
- list whose name is "<code
- title="http-websocket-location">websocket-location</code>", or if
- the <var title="">protocol</var> was specified but there is not
- exactly one entry in the <var title="">headers</var> list whose
- name is "<code
- title="http-websocket-protocol">websocket-protocol</code>", or if
- there are any entries in the <var title="">headers</var> list
- whose names are the empty string, then <span>fail the Web Socket
+ <p>
+ <!--(v2-redirect or v2-ws-auth) If <var title="">mode</var> is <i title="">normal</i>, then: -->
+
+ If there is not exactly one entry in the <var
+ title="">fields</var> list whose name is "<code
+ title="http-upgrade">upgrade</code>", or
+
+ if there is not exactly one entry in the <var
+ title="">fields</var> list whose name is "<code
+ title="http-connection">connection</code>", or
+
+ if there is not exactly one entry in the <var
+ title="">fields</var> list whose name is "<code
+ title="http-sec-websocket-origin">sec-websocket-origin</code>", or
+
+ if there is not exactly one entry in the <var
+ title="">fields</var> list whose name is "<code
+ title="http-sec-websocket-location">sec-websocket-location</code>", or
+
+ if the <var title="">protocol</var> was specified but there is not exactly one entry in the <var
+ title="">fields</var> list whose name is "<code
+ title="http-sec-websocket-protocol">sec-websocket-protocol</code>", or
+
+ if there are any entries in the <var title="">fields</var> list
+ whose names are the empty string, then <span>fail the WebSocket
connection</span> and abort these steps. Otherwise, handle each
- entry in the <var title="">headers</var> list as follows:</p>
+ entry in the <var title="">fields</var> list as follows:</p>
<dl class="switch">
<dt>If the entry's name is "<code
- title="http-websocket-origin">websocket-origin</code>"</dt>
+ title="http-upgrade">upgrade</code>"</dt>
+ <dd><p>If the value is not exactly equal to the string
+ "WebSocket", then <span>fail the WebSocket connection</span> and
+ abort these steps.</p></dd>
+
+
+ <dt>If the entry's name is "<code
+ title="http-connection">connection</code>"</dt>
+
+ <dd><p>If the value, <span>converted to ASCII lowercase</span>,
+ is not exactly equal to the string "upgrade", then <span>fail the
+ WebSocket connection</span> and abort these steps.</p></dd>
+
+
+ <dt>If the entry's name is "<code
+ title="http-sec-websocket-origin">sec-websocket-origin</code>"</dt>
+
<dd><p>If the value is not exactly equal to <var
title="">origin</var>, <span>converted to ASCII lowercase</span>,
- then <span>fail the Web Socket connection</span> and abort these
+ then <span>fail the WebSocket connection</span> and abort these
steps. <a href="#refsORIGIN">[ORIGIN]</a></p></dd>
<dt>If the entry's name is "<code
- title="http-websocket-location">websocket-location</code>"</dt>
+ title="http-sec-websocket-location">sec-websocket-location</code>"</dt>
<dd>
<p>If the value is not exactly equal to a string obtained from
- the steps to <span>construct a Web Socket URL</span> from <var
+ the steps to <span>construct a WebSocket URL</span> from <var
title="">host</var>, <var title="">port</var>, <var
title="">resource name</var>, and the <var title="">secure</var>
- flag, then <span>fail the Web Socket connection</span> and abort
+ flag, then <span>fail the WebSocket connection</span> and abort
these steps.</p>
</dd>
<dt>If the entry's name is "<code
- title="http-websocket-protocol">websocket-protocol</code>"</dt>
+ title="http-sec-websocket-protocol">sec-websocket-protocol</code>"</dt>
<dd><p>If there was a <var title="">protocol</var> specified, and
the value is not exactly equal to <var title="">protocol</var>,
- then <span>fail the Web Socket connection</span> and abort these
+ then <span>fail the WebSocket connection</span> and abort these
steps. (If no <var title="">protocol</var> was specified, the
- header is ignored.)</p></dd>
+ field is ignored.)</p></dd>
<dt>If the entry's name is "<code
title="http-setcookie">set-cookie</code>" or "<code
title="http-setcookie2">set-cookie2</code>" or another
- cookie-related header name</dt>
+ cookie-related field name</dt>
<dd><p>Handle the cookie as defined by the appropriate
specification, with the resource being the one with the host <var
@@ -76632,10 +76905,10 @@
<p>If <var title="">mode</var> is <i title="">redirect</i>, then:
If there is not exactly one entry in the <var
- title="">headers</var> list whose name is "<code
- title="">location</code>", then <span>fail the Web Socket
+ title="">fields</var> list whose name is "<code
+ title="">location</code>", then <span>fail the WebSocket
connection</span> and abort these steps. Otherwise, handle each
- entry in the <var title="">headers</var> list as follows:</p>
+ entry in the <var title="">fields</var> list as follows:</p>
<dl class="switch">
@@ -76649,20 +76922,20 @@
<li><p>Let <var title="">was secure</var> have the value of
<var title="">secure</var>.</p></li>
- <li><p><span>Parse a Web Socket URL's components</span> from
+ <li><p><span>Parse a WebSocket URL's components</span> from
the <var title="">url</var> argument, to obtain new values for
<var title="">host</var>, <var title="">port</var>, <var
title="">resource name</var>, and <var
- title="">secure</var>. If this fails, <span>fail the Web Socket
+ title="">secure</var>. If this fails, <span>fail the WebSocket
connection</span> and abort these steps.</p></li>
<li><p>If <var title="">was secure</var> is true but <var
- title="">secure</var> is now false, <span>fail the Web Socket
+ title="">secure</var> is now false, <span>fail the WebSocket
connection</span> and abort these steps.</p></li>
<li><p>If <var title="">port</var> is a port to which the user
- agent is configured to block access, then <span>fail the Web
- Socket connection</span> and abort these steps. (User agents
+ agent is configured to block access, then <span>fail the
+ WebSocket connection</span> and abort these steps. (User agents
typically block access to well-known ports like SMTP.)</p></li>
<li><p>Close the connection if the server has not already done
@@ -76688,10 +76961,10 @@
<p>If <var title="">mode</var> is <i title="">authenticate</i>,
then: If there is not exactly one entry in the <var
- title="">headers</var> list whose name is "<code
- title="">www-authenticate</code>", then <span>fail the Web Socket
+ title="">fields</var> list whose name is "<code
+ title="">www-authenticate</code>", then <span>fail the WebSocket
connection</span> and abort these steps. Otherwise, handle each
- entry in the <var title="">headers</var> list as follows:</p>
+ entry in the <var title="">fields</var> list as follows:</p>
<dl class="switch">
@@ -76722,7 +76995,62 @@
<li>
- <p>The <dfn>Web Socket connection is established</dfn>. Now the
+ <p>Let <var title="">challenge</var> be the concatenation of <var
+ title="">number<sub>1</sub></var>, expressed as a little-endian 32
+ bit integer, <var title="">number<sub>2</sub></var>, expressed as
+ a little-endian 32 bit integer, and the eight bytes of <var
+ title="">key<sub>3</sub></var> in the order they were sent on the
+ wire.</p>
+
+ <!--
+ perl -e 'foreach (@ARGV) { print pack 'N', $_ }' 777007543 114997259 | hexdump -C
+ -->
+
+ <p class="example">Using the examples given earlier, this leads to
+ the 16 bytes 0x2E 0x50 0x31 0xB7 0x06 0xDA 0xB8 0x0B 0x47 0x30
+ 0x22 0x2D 0x5A 0x3F 0x47 0x58.</p>
+
+ </li>
+
+ <li>
+
+ <p>Let <var title="">expected</var> be the MD5 fingerprint of <var
+ title="">challenge</var> as a little-endian 128 bit string. <a
+ href="#refsRFC1321">[RFC1321]</a></p>
+
+ <!--
+ perl -e "print pack 'c*', map { hex } @ARGV" 0x2E 0x50 0x31 0xB7 0x06 0xDA 0xB8 0x0B 0x47 0x30 0x22 0x2D 0x5A 0x3F 0x47 0x58 | md5sum -b
+ -->
+
+ <p class="example">Using the examples given earlier, this leads to
+ the 16 bytes 0x30 0x73 0x74 0x33 0x52 0x6C 0x26 0x71 0x2D 0x32
+ 0x5A 0x55 0x5E 0x77 0x65 0x75. In ASCII, these bytes correspond to
+ the string "0st3Rl&q-2ZU^weu".</p>
+
+ </li>
+
+ <li>
+
+ <p>Read sixteen bytes from the server. Let <var
+ title="">reply</var> be those bytes.</p>
+
+ <p>If the connection closes before these bytes are received, then
+ <span>fail the WebSocket connection</span> and abort these
+ steps.</p>
+
+ </li>
+
+ <li>
+
+ <p>If <var title="">reply</var> does not exactly equal <var
+ title="">expected</var>, then <span>fail the WebSocket
+ connection</span> and abort these steps.</p>
+
+ </li>
+
+ <li>
+
+ <p>The <dfn>WebSocket connection is established</dfn>. Now the
user agent must send and receive to and from the connection as
described in the next section.</p>
@@ -76733,7 +77061,7 @@
<h6>Data framing</h6>
- <p>Once a <span>Web Socket connection is established</span>, the
+ <p>Once a <span>WebSocket connection is established</span>, the
user agent must run through the following state machine for the
bytes sent by the server.</p>
@@ -76744,7 +77072,7 @@
<p>Try to read a byte from the server. Let <var title="">frame
type</var> be that byte.</p>
- <p>If no byte could be read because the <span>Web Socket
+ <p>If no byte could be read because the <span>WebSocket
connection is closed</span>, then abort.</p>
</li>
@@ -76762,7 +77090,7 @@
<dd>
<p>Run these steps. If at any point during these steps a read is
- attempted but fails because the <span>Web Socket connection is
+ attempted but fails because the <span>WebSocket connection is
closed</span>, then abort.</p>
<ol>
@@ -76801,7 +77129,7 @@
<dd>
<p>Run these steps. If at any point during these steps a read is
- attempted but fails because the <span>Web Socket connection is
+ attempted but fails because the <span>WebSocket connection is
closed</span>, then abort.</p>
<ol>
@@ -76820,7 +77148,7 @@
string, and store that string in <var title="">data</var>.</p>
<li><p>If <var title="">frame type</var> is 0x00, then <dfn>a
- message has been received</dfn> with text <var
+ WebSocket message has been received</dfn> with text <var
title="">data</var>. Otherwise, discard the data.</p></li>
</ol>
@@ -76838,14 +77166,14 @@
<p>If the user agent is faced with content that is too large to be
handled appropriately, runs out of resources for buffering incoming
data, or hits an artificial resource limit intended to avoid
- resource starvation, then it must <span>fail the Web Socket
+ resource starvation, then it must <span>fail the WebSocket
connection</span>.</p>
<hr>
- <p>Once a <span>Web Socket connection is established</span>, the
+ <p>Once a <span>WebSocket connection is established</span>, the
user agent must use the following steps to <dfn>send <var
- title="">data</var> using the Web Socket</dfn>:</p>
+ title="">data</var> using the WebSocket</dfn>:</p>
<ol>
@@ -76859,7 +77187,7 @@
</ol>
<p>If at any point there is a fatal problem with sending data to the
- server, the user agent must <span>fail the Web Socket
+ server, the user agent must <span>fail the WebSocket
connection</span>.</p>
<!-- v2: People often request the ability to send binary blobs over
@@ -76868,17 +77196,17 @@
data. -->
- <h6>Closing the connection</h6>
+ <h6>Failing the connection</h6>
- <p>To <dfn>fail the Web Socket connection</dfn>, the user agent must
- <span>close the Web Socket connection</span>, and may report the
+ <p>To <dfn>fail the WebSocket connection</dfn>, the user agent must
+ <span>close the WebSocket connection</span>, and may report the
problem to the user (which would be especially useful for
developers). However, user agents must not convey the failure
information to the script that attempted the connection in a way
- distinguishable from the Web Socket being closed normally.</p>
+ distinguishable from the WebSocket being closed normally.</p>
<p>Except as indicated above or as specified by the application
- layer (e.g. a script using the Web Socket API), user agents should
+ layer (e.g. a script using the WebSocket API), user agents should
not close the connection.</p>
@@ -76894,200 +77222,178 @@
<h5>Server-side requirements</h5>
<p><i>This section only applies to servers.</i></p>
-
- <h6>Sending the server's handshake</h6>
- <p>When a client establishes a Web Socket connection to a server,
- the server must either close the connection or send the server
- handshake. Servers may read part or all of the client's handshake
- (as described in the next section) before closing the connection or
- sending all of their side of the handshake; indeed, in some cases
- this is necessary as the server might need to use some of the
- information in the client's handshake to construct it's own
- handshake.</p>
+ <h6>Reading the client's handshake</h6>
- <p>If the server supports encryption, then the server must perform a
- TLS handshake over the connection before sending the server
- handshake. If this fails (e.g. the client indicated a host name in
- the extended client hello "server_name" extension that the server
- does not host), then the server must close the connection;
- otherwise, all further communication for the connection (including
- the server handshake) must run through the encrypted tunnel. <a
- href="#refsRFC2246">[RFC2246]</a></p>
+ <p>When a client starts a WebSocket connection, it sends its part of
+ the handshake. The server must parse at least part of this handshake
+ in order to obtain the necessary information to generate the server
+ part of the handshake.</p>
- <p>To send the server handshake, the server must first establish the
- following information:</p>
+ <p>The client handshake consists of the following parts. If the
+ server, while reading the handshake, finds that the client did not
+ send a handshake that matches the description below, the server
+ should <span>abort the WebSocket connection</span>.</p>
- <dl>
+ <ol>
- <dt><var title="">origin</var></dt>
+ <li><p>The three-character UTF-8 string "GET".</p></li>
- <dd>The <span title="ASCII serialization of an origin">ASCII
- serialization</span> of the origin that the server is willing to
- communicate with. If the server can respond to requests from
- multiple origins (or indeed, all origins), then the value should be
- derived from the client's handshake, specifically from the "Origin"
- field. <a href="#refsORIGIN">[ORIGIN]</a></dd>
+ <li><p>A UTF-8-encoded U+0020 SPACE character (0x20 byte).</p></li>
- <dt><var title="">host</var></dt>
+ <li><p>A string consisting of all the bytes up to the next
+ UTF-8-encoded U+0020 SPACE character (0x20 byte). The result of
+ decoding this string as a UTF-8 string is the name of the resource
+ requested by the server. If the server only supports one resource,
+ then this can safely be ignored; the client verifies that the right
+ resource is supported based on the information included in the
+ server's own handshake. The resource name will begin with U+002F
+ SOLIDUS character (/) and will only include characters in the range
+ U+0021 to U+007E.</p></li>
- <dd>The host name or IP address of the Web Socket server, as it is
- to be addressed by clients. The host name must be punycode-encoded
- if necessary. If the server can respond to requests to multiple
- hosts (e.g. in a virtual hosting environment), then the value
- should be derived from the client's handshake, specifically from
- the "Host" field.</dd>
+ <li><p>A string of bytes terminated by a UTF-8-encoded U+000D
+ CARRIAGE RETURN U+000A LINE FEED character pair (CRLF). All the
+ characters from the second 0x20 byte up to the first 0x0D 0x0A byte
+ pair in the data from the client can be safely ignored. (It will
+ probably be the string "HTTP/1.1".)</p>
- <dt><var title="">port</var></dt>
+ <li>
- <dd>The port number on which the server expected and/or received
- the connection.</dd>
+ <p>A series of fields.</p>
- <dt><var title="">resource name</var></dt>
+ <p>Each field is terminated by a UTF-8-encoded U+000D CARRIAGE
+ RETURN U+000A LINE FEED character pair (CRLF). The end of the
+ fields is denoted by the terminating CRLF pair being followed
+ immediately by another CRLF pair.</p>
- <dd>An identifier for the service provided by the server. If the
- server provides multiple services, then the value should be derived
- from the client's handshake, specifically from the "Host"
- field.</dd>
+ <p class="note">In other words, the fields start with the first
+ 0x0D 0x0A byte pair and end with the first 0x0D 0x0A 0x0D 0x0A
+ byte sequence.</p>
- <dt><var title="">secure flag</var><dt>
+ <p>The fields are encoded as UTF-8.</p>
- <dd>True if the connection is encrypted or if the server expected
- it to be encrypted; false otherwise.</dd>
+ <p>Each field consists of a name, consisting of one or more
+ characters in the range U+0021 to U+007E, followed by a U+003A
+ COLON character (:) and a U+0020 SPACE character, followed by zero
+ or more characters forming the value.</p>
- <dt><var title="">subprotocol</var></dt>
+ <p>The expected field names, the meaning of their corresponding
+ values, and the processing servers are required to apply to those
+ fields, are described below, after the description of the client
+ handshake.</p>
- <dd>Either null, or a string representing the subprotocol the
- server is ready to use. If the server supports multiple
- subprotocols, then the value should be derived from the client's
- handshake, specifically from the "WebSocket-Protocol" field. The
- absence of such a field is equivalent to the null value. The empty
- string is not the same as the null value for these purposes.</dd>
+ </li>
- </dl>
+ <li>
- <p>Having established this information, the server must start the
- handshake. The initial part of the server's handshake is invariant,
- and must consist of the following bytes:</p>
+ <p>After the first 0x0D 0x0A 0x0D 0x0A byte sequence, indicating
+ the end of the fields, the client sends eight random bytes. These
+ are used in constructing the server handshake.</p>
- <pre>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 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 57 65 62 53 6F 63 6B 65 74 2D 4F
-72 69 67 69 6E 3A 20</pre>
+ </li>
- <p>These bytes must be the first bytes sent on the TCP connection by
- the server. They must be followed by the <var title="">origin</var>
- string, encoded as ANSI_X3.4-1968 (US-ASCII), followed by the
- following bytes: <a href="#refsRFC1345">[RFC1345]</a></p>
+ </ol>
- <pre>0D 0A 57 65 62 53 6F 63 6B 65 74 2D 4C 6F 63 61
-74 69 6F 6E 3A 20</pre>
+ <p>The expected field names, and the meaning of their corresponding
+ values, are as follows. Field names must be compared in an
+ <span>ASCII case-insensitive</span> manner.</p>
- <p>The server must then send the string that results from <span
- title="construct a Web Socket URL">constructing a Web Socket
- URL</span> from <var title="">host</var>, <var title="">port</var>,
- <var title="">resource name</var>, and <var title="">secure
- flag</var>, encoded as ANSI_X3.4-1968 (US-ASCII). <a
- href="#refsRFC1345">[RFC1345]</a></p>
-
- <p>If the <var title="">subprotocol</var> is not null, then the
- server must then send the following bytes:</p>
-
- <pre>0D 0A 57 65 62 53 6F 63 6B 65 74 2D 50 72 6F 74
-6F 63 6F 6C 3A 20</pre>
-
- <p>...followed by the <var title="">subprotocol</var> string,
- encoded as ANSI_X3.4-1968 (US-ASCII). <a
- href="#refsRFC1345">[RFC1345]</a></p>
-
- <p>Finally, the server must end its side of the handshake by sending
- the four bytes 0x0D 0x0A 0x0D 0x0A to the client.</p>
-
-
- <h6>Reading the client's handshake</h6>
-
- <p>When a client starts a Web Socket connection, it sends its part
- of the handshake. This consists of a number of fields separated by
- CRLF pairs (bytes 0x0D 0x0A).</p>
-
- <p>The first field consists of three tokens separated by space
- characters (byte 0x20). The first token is the string "GET", the
- middle token is the resource name, and the third is the string
- "HTTP/1.1".</p>
-
- <p>If the first field does not have three tokens, or if the first
- and third tokens aren't the strings given in the previous paragraph,
- or if the second token doesn't begin with U+002F SOLIDUS character
- (/), the server should abort the connection: it either represents an
- errorneous Web Socket client or a connection from a client expecting
- another protocol altogether.</p>
-
- <p>The subsequent fields consist of a string representing a name, a
- colon and a space (bytes 0x3A 0x20), and a string representing a
- value. The possible names, and the meaning of their corresponding
- values, are as follows:</p>
-
<dl>
- <dt>Upgrade (bytes 55 70 67 72 61 64 65; always the first name-value pair)</dt>
+ <dt><code title="http-upgrade">Upgrade</code></dt>
<dd>
- <p>Invariant part of the handshake. Will always have a value
- consisting of bytes 57 65 62 53 6F 63 6B 65 74.</p>
+ <p>Invariant part of the handshake. Will always have a value that
+ is an <span>ASCII case-insensitive</span> match for the string
+ "WebSocket".</p>
+ <p>Can be safely ignored, though the server should <span>abort the WebSocket
+ connection</span> if this field is absent or has a different
+ value, to avoid vulnerability to cross-protocol attacks.</p>
+
</dd>
- <dt>Connection (bytes 43 6F 6E 6E 65 63 74 69 6F 6E; always the second name-value pair)</dt>
+ <dt><code title="http-connection">Connection</code></dt>
<dd>
- <p>Invariant part of the handshake. Will always have a value
- consisting of bytes 55 70 67 72 61 64 65.</p>
+ <p>Invariant part of the handshake. Will always have a value that
+ is an <span>ASCII case-insensitive</span> match for the string
+ "Upgrade".</p>
+ <p>Can be safely ignored, though the server should <span>abort the WebSocket
+ connection</span> if this field is absent or has a different
+ value, to avoid vulnerability to cross-protocol attacks.</p>
+
</dd>
- <dt>Host (bytes 48 6F 73 74; always the third name-value pair)</dt>
+ <dt><code title="http-host">Host</code></dt>
<dd>
<p>The value gives the hostname that the client intended to use
- when opening the Web Socket. It would be of interest in particular
+ when opening the WebSocket. It would be of interest in particular
to virtual hosting environments, where one server might serve
multiple hosts, and might therefore want to return different
- data. The value must be interpreted as UTF-8.</p>
+ data.</p>
+ <p>Can be safely ignored, though the server should <span>abort the WebSocket
+ connection</span> if this field is absent or has a value that
+ does not match the server's host name, to avoid vulnerability to
+ cross-protocol attacks and DNS rebinding attacks.</p>
+
</dd>
- <dt>Origin (bytes 4F 72 69 67 69 6E; always the fourth name-value pair)</dt> <!-- http-origin -->
+ <dt><code title="http-origin">Origin</code></dt>
<dd>
<p>The value gives the scheme, hostname, and port (if it's not the
default port for the given scheme) of the page that asked the
- client to open the Web Socket. It would be interesting if the
+ client to open the WebSocket. It would be interesting if the
server's operator had deals with operators of other sites, since
the server could then decide how to respond (or indeed,
<em>whether</em> to respond) based on which site was requesting a
- connection. The value must be interpreted as UTF-8.</p>
+ connection. <a href="#refsORIGIN">[ORIGIN]</a></p>
+ <p>Can be safely ignored, though the server should <span>abort the WebSocket
+ connection</span> if this field is absent or has a value that
+ does not match one of the origins the server is expecting to
+ communicate with, to avoid vulnerability to cross-protocol attacks
+ and cross-site scripting attacks.</p>
+
</dd>
- <dt>WebSocket-Protocol (bytes 57 65 62 53 6F 63 6B 65 74 2D 50 72 6F 74 6F 63 6F 6C; optional, if present, will be the fifth name-value pair)</dt> <!-- http-websocket-protocol -->
+ <dt><code title="http-sec-websocket-protocol">Sec-WebSocket-Protocol</code></dt>
<dd>
<p>The value gives the name of a subprotocol that the client is
intending to select. It would be interesting if the server
- supports multiple protocols or protocol versions. The value must
- be interpreted as UTF-8.</p>
+ supports multiple protocols or protocol versions.</p>
+ <p>Can be safely ignored, though the server may <span>abort the WebSocket
+ connection</span> if the field is absent but the conventions for
+ communicating with the server are such that the field is
+ expected; and the server should <span>abort the WebSocket connection</span>
+ if the field has a value that does not match one of the
+ subprotocols that the server supports, to avoid integrity errors
+ once the connection is established.</p>
+
</dd>
+ <dt><code title="http-sec-websocket-key1">Sec-WebSocket-Key1</code></dt>
+ <dt><code title="http-sec-websocket-key2">Sec-WebSocket-Key2</code></dt>
+
+ <dd>
+
+ <p>The values provide the information required for computing the
+ server's handshake, as described in the next section.</p>
+
+ </dd>
+
<dt>Other fields</dt>
<dd>
@@ -77104,35 +77410,337 @@
connect (e.g. because they are on an intranet firewalled from the
public Internet), then the server should also verify that the
client's handshake includes the invariant "Upgrade" and
- "Connection" parts of the handshake. Otherwise, an attacker could
- trick a client into sending Web Socket frames to a server
+ "Connection" parts of the handshake, and should send the server's
+ handshake before changing any user data. Otherwise, an attacker
+ could trick a client into sending WebSocket frames to a server
(e.g. using <code>XMLHttpRequest</code>) and cause the server to
perform actions on behalf of the user without the user's
- consent.</p>
+ consent. (Sending the server's handshake ensures that the frames
+ were not sent as part of a cross-protocol attack, since other
+ protocols do not send the necessary components in the client's
+ initial handshake for forming the server's handshake.)</p>
</dd>
</dl>
- <p>A final field consisting of the empty string (two consecutive
- CRLF pairs) indicates the end of the client's handshake.</p>
+ <p>Unrecognised fields can be safely ignored, and are probably
+ either the result of intermediaries injecting fields unrelated to
+ the operation of the WebSocket protocol, or clients that support
+ future versions of the protocol offering options that the server
+ doesn't support.</p>
- <p>Any fields that lack the colon-space separator must at a minimum
- be discarded and may cause the server to disconnect.</p>
+
+ <h6>Sending the server's handshake</h6>
- <p>Whether the server does or does not read the client handshake, it
- must at a minimum read (and optionally discard) bytes until it has
- read the first sequence of four bytes 0x0A 0x0D 0x0A 0x0D, which
- signals the end of the client handshake. Servers may do this before
- or after sending their handshake, but must do it before reading
- frames from the client as described in the next section.</p>
+ <p>When a client establishes a WebSocket connection to a server, the
+ server must run the following steps.</p>
+ <ol>
+ <li>
+
+ <p>If the server supports encryption, perform a TLS handshake over
+ the connection. If this fails (e.g. the client indicated a host
+ name in the extended client hello "server_name" extension that the
+ server does not host), then close the connection; otherwise, all
+ further communication for the connection (including the server
+ handshake) must run through the encrypted tunnel. <a
+ href="#refsRFC2246">[RFC2246]</a></p>
+
+ </li>
+
+ <li>
+
+ <p>Establish the following information:</p>
+
+ <dl>
+
+ <dt><var title="">host</var></dt>
+
+ <dd>The host name or IP address of the WebSocket server, as it is
+ to be addressed by clients. The host name must be
+ punycode-encoded if necessary. If the server can respond to
+ requests to multiple hosts (e.g. in a virtual hosting
+ environment), then the value should be derived from the client's
+ handshake, specifically from the "<code
+ title="http-host">Host</code>" field.</dd>
+
+ <dt><var title="">port</var></dt>
+
+ <dd>The port number on which the server expected and/or received
+ the connection.</dd>
+
+ <dt><var title="">resource name</var></dt>
+
+ <dd>An identifier for the service provided by the server. If the
+ server provides multiple services, then the value should be
+ derived from the resource name given in the client's
+ handshake.</dd>
+
+ <dt><var title="">secure flag</var><dt>
+
+ <dd>True if the connection is encrypted or if the server expected
+ it to be encrypted; false otherwise.</dd>
+
+ <dt><var title="">origin</var></dt>
+
+ <dd>The <span title="ASCII serialization of an origin">ASCII
+ serialization</span> of the origin that the server is willing to
+ communicate with. If the server can respond to requests from
+ multiple origins (or indeed, all origins), then the value should
+ be derived from the client's handshake, specifically from the
+ "<code title="http-origin">Origin</code>" field. <a
+ href="#refsORIGIN">[ORIGIN]</a></dd>
+
+ <dt><var title="">subprotocol</var></dt>
+
+ <dd>Either null, or a string representing the subprotocol the
+ server is ready to use. If the server supports multiple
+ subprotocols, then the value should be derived from the client's
+ handshake, specifically from the "<code
+ title="http-sec-websocket-protocol">Sec-WebSocket-Protocol</code>"
+ field. The absence of such a field is equivalent to the null
+ value. The empty string is not the same as the null value for
+ these purposes.</dd>
+
+ <dt><var title="">key1</var></dt>
+
+ <dd>The value of the "<code
+ title="http-sec-websocket-key1">Sec-WebSocket-Key1</code>"
+ field in the client's handshake.</dd>
+
+ <dt><var title="">key2</var></dt>
+
+ <dd>The value of the "<code
+ title="http-sec-websocket-key2">Sec-WebSocket-Key2</code>"
+ field in the client's handshake.</dd>
+
+ <dt><var title="">key3</var></dt>
+
+ <dd>The eight random bytes sent after the first 0x0D 0x0A 0x0D
+ 0x0A sequence in the client's handshake.</dd>
+
+ </dl>
+
+ </li>
+
+ <li>
+
+ <p>Let <var title="">location</var> be the string that results
+ from <span title="construct a WebSocket URL">constructing a
+ WebSocket URL</span> from <var title="">host</var>, <var
+ title="">port</var>, <var title="">resource name</var>, and <var
+ title="">secure flag</var>.</p>
+
+ </li>
+
+ <li>
+
+ <p>Let <var title="">key1-number</var> be the digits (characters
+ in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9)) in
+ <var title="">key1</var>, interpreted as a base ten integer,
+ ignoring all other characters in <var title="">key1</var>.</p>
+
+ <p>Let <var title="">key2-number</var> be the digits (characters
+ in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9)) in
+ <var title="">key2</var>, interpreted as a base ten integer,
+ ignoring all other characters in <var title="">key2</var>.</p>
+
+ <div class="example">
+
+ <p>For example, assume that the client handshake was:</p>
+
+ <pre>GET / HTTP/1.1
+Connection: Upgrade
+Host: example.com
+Upgrade: WebSocket
+Sec-WebSocket-Key1: 3e6b263 4 17 80
+Origin: http://example.com
+Sec-WebSocket-Key2: 17 9 G`ZD9 2 2b 7X 3 /r90
+
+WjN}|M(6</pre>
+
+ <p>The <var title="">key1-number</var> would be the number
+ 3,626,341,780, and the <var title="">key2-number</var> would be
+ the number 1,799,227,390.</p>
+
+ <p>In this example, incidentally, <var title="">key3</var> is
+ "WjN}|M(6", or 0x57 0x6A 0x4E 0x7D 0x7C 0x4D 0x28 0x36.</p>
+
+ </div>
+
+ </li>
+
+ <li>
+
+ <p>Let <var title="">spaces1</var> be the number of U+0020 SPACE
+ characters in <var title="">key1</var>.</p>
+
+ <p>Let <var title="">spaces2</var> be the number of U+0020 SPACE
+ characters in <var title="">key2</var>.</p>
+
+ <p>If either <var title="">spaces1</var> or <var
+ title="">spaces2</var> is zero, then <span>abort the WebSocket
+ connection</span>. This is a symptom of a cross-protocol
+ attack.</p>
+
+ <p class="example">In the example above, <var
+ title="">spaces1</var> would be 4 and <var title="">spaces2</var>
+ would be 10.</p>
+
+ </li>
+
+ <li>
+
+ <p>If <var title="">key1-number</var> is not an integral multiple
+ of <var title="">spaces1</var>, then <span>abort the WebSocket
+ connection</span>.</p>
+
+ <p>If <var title="">key2-number</var> is not an integral multiple
+ of <var title="">spaces2</var>, then <span>abort the WebSocket
+ connection</span>.</p>
+
+ <p class="note">This can only happen if the client is not a
+ conforming WebSocket client.</p>
+
+ </li>
+
+ <li>
+
+ <p>Let <var title="">part1</var> be <var
+ title="">key1-number</var> divided by <var title="">spaces1</var>.</p>
+
+ <p>Let <var title="">part2</var> be <var
+ title="">key2-number</var> divided by <var title="">spaces2</var>.</p>
+
+ <p class="example">In the example above, <var title="">part1</var>
+ would be 906,585,445 and <var title="">part2</var> would be
+ 179,922,739.</p>
+
+ </li>
+
+ <li>
+
+ <p>Let <var title="">challenge</var> be the concatenation of <var
+ title="">part1</var>, expressed as a little-endian 32 bit integer,
+ <var title="">part2</var>, expressed as a little-endian 32 bit
+ integer, and the eight bytes of <var title="">key3</var> in the
+ order they were sent on the wire.</p>
+
+ <!--
+ perl -e 'foreach (@ARGV) { print pack 'N', $_ }' 906585445 179922739 | hexdump -C
+ -->
+
+ <p class="example">In the example above, this would be the 16
+ bytes 0x36 0x09 0x65 0x65 0x0A 0xB9 0x67 0x33 0x57 0x6A 0x4E 0x7D
+ 0x7C 0x4D 0x28 0x36.</p>
+
+ </li>
+
+ <li>
+
+ <p>Let <var title="">response</var> be the MD5 fingerprint of <var
+ title="">challenge</var> as a little-endian 128 bit string. <a
+ href="#refsRFC1321">[RFC1321]</a></p>
+
+ <!--
+ perl -e "print pack 'c*', map { hex } @ARGV" 0x36 0x09 0x65 0x65 0x0A 0xB9 0x67 0x33 0x57 0x6A 0x4E 0x7D 0x7C 0x4D 0x28 0x36 | md5sum -b
+ -->
+
+ <p class="example">In the example above, this would be the 16
+ bytes 0x6E 0x60 0x39 0x65 0x42 0x6B 0x39 0x7A 0x24 0x52 0x38 0x70
+ 0x4F 0x74 0x56 0x62, or "n`9eBk9z$R8pOtVb" in ASCII.
+
+ </li>
+
+ <li>
+
+ <p>Send the following line, terminated by the two characters
+ U+000D CARRIAGE RETURN and U+000A LINE FEED (CRLF) and encoded as
+ UTF-8, to the client:</p>
+
+ <pre>HTTP/1.1 101 WebSocket Protocol Handshake</pre>
+
+ <p>This line may be sent differently if necessary, but must match
+ the Status-Line production defined in the HTTP specification, with
+ the Status-Code having the value 101.</p>
+
+ </li>
+
+ <li>
+
+ <p>Send the following fields to the client. Each field must be
+ sent as a line consisting of the field name, which must be an
+ <span>ASCII case-insensitive</span> match for the field name in
+ the list below, followed by a U+003A COLON character (:) and a
+ U+0020 SPACE character, followed by the field value as specified
+ in the list below, followed by the two characters U+000D CARRIAGE
+ RETURN and U+000A LINE FEED (CRLF). The lines must be encoded as
+ UTF-8. The lines may be sent in any order.</p>
+
+ <dl>
+
+ <dt><code title="http-upgrade">Upgrade</code></dt>
+
+ <dd><p>The value must be the string "WebSocket".</p></dd>
+
+ <dt><code title="http-connection">Connection</code></dt>
+
+ <dd><p>The value must be the string "Upgrade".</p></dd>
+
+ <dt><code title="http-sec-websocket-location">Sec-WebSocket-Location</code></dt>
+
+ <dd><p>The value must be <var title="">location</var></p></dd>
+
+ <dt><code title="http-sec-websocket-origin">Sec-WebSocket-Origin</code></dt>
+
+ <dd><p>The value must be <var title="">origin</var></p></dd>
+
+ <dt><code title="http-sec-websocket-protocol">Sec-WebSocket-Protocol</code></dt>
+
+ <dd>
+
+ <p>This field must be included if <var
+ title="">subprotocol</var> is not null, and must not be included
+ if <var title="">subprotocol</var> is null.</p>
+
+ <p>If included, the value must be <var title="">subprotocol</var></p>
+
+ </dd>
+
+ </dl>
+
+ </li>
+
+ <li>
+
+ <p>Send two bytes 0x0D 0x0A (ASCII CRLF).</p>
+
+ </li>
+
+ <li>
+
+ <p>Send <var title="">response</var>.</p>
+
+ </li>
+
+ </ol>
+
+ <p>This completes the server's handshake. If the server finishes
+ these steps without <span title="abort the WebSocket
+ connection">aborting the WebSocket connection</span>, and if the
+ client does not then <span>fail the connection</span>, then the
+ connection is established and the server may begin and receiving
+ sending data, as described in the next section.</p>
+
+
+
<h6 id="ws-sd-framing">Data framing</h6>
<p>The server must run through the following steps to process the
bytes sent by the client. If at any point during these steps a read
- is attempted but fails because the <span>Web Socket connection is
+ is attempted but fails because the <span>WebSocket connection is
closed</span>, then abort.</p>
<ol>
@@ -77226,6 +77834,13 @@
</ol>
+ <h6>Aborting the connection</h6>
+
+ <p>To <dfn>abort the WebSocket connection</dfn> during the
+ handshake, the server must <span>close the WebSocket
+ connection</span>.</p>
+
+
<h6>Handling errors in UTF-8</h6>
<p>When a server is to interpret a byte stream as UTF-8 but finds
@@ -77233,23 +77848,25 @@
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 Web Socket protocol might define specific behavior
+ layered on the WebSocket protocol might define specific behavior
for servers.</p>
<h5>Closing the connection</h5>
- <p>To <dfn>close the Web Socket connection</dfn>, either the user
- agent or the server closes the TCP/IP connection. There is no
+ <p>To <dfn>close the WebSocket connection</dfn>, either the user
+ agent or the server closes the TCP connection. There is no
closing handshake. When a user agent notices that the server has
closed its connection, it must immediately close its side of the
connection also. Whether the user agent or the server closes the
- connection first, it is said that the <dfn>Web Socket connection is
+ connection first, it is said that the <dfn>WebSocket connection is
closed</dfn>.</p>
- <p>Servers may <span>close the Web Socket connection</span> whenever
- desired. User agents should not <span>close the Web Socket
+ <!-- XXX Close Handshake but NOT for FAILing or ABORTing -->
+
+ <p>Servers may <span>close the WebSocket connection</span> whenever
+ desired. User agents should not <span>close the WebSocket
connection</span> arbitrarily.</p>
@@ -77258,7 +77875,7 @@
<p>While this protocol is intended to be used by scripts in Web
pages, it can also be used directly by hosts. Such hosts are acting
- on their own behalf, and can therefore send fake "Origin" headers,
+ on their own behalf, and can therefore send fake "Origin" fields,
misleading the server. Servers should therefore be careful about
assuming that they are talking directly to scripts from known
origins, and must consider that they might be accessed in unexpected
@@ -77272,12 +77889,12 @@
<hr>
<p>Servers that are not intended to process input from any Web page
- but only for certain sites should verify the "Origin" header is an
+ but only for certain sites should verify the "Origin" field is an
origin they expect, and should only respond with the corresponding
- "WebSocket-Origin" if it is an accepted origin. Servers that only
- accept input from one origin can just send back that value in the
- "WebSocket-Origin" header, without bothering to check the client's
- value.</p>
+ "Sec-WebSocket-Origin" if it is an accepted origin. Servers that
+ only accept input from one origin can just send back that value in
+ the "Sec-WebSocket-Origin" field, without bothering to check the
+ client's value.</p>
<hr>
@@ -77301,7 +77918,7 @@
<h6>Registration of <code title="">ws:</code> scheme</h6>
- <p>A <code title="">ws:</code> URL identifies a Web Socket server
+ <p>A <code title="">ws:</code> URL identifies a WebSocket server
and resource name.</p>
<dl>
@@ -77330,7 +77947,7 @@
<dt>URI scheme semantics.</dt>
<dd>The only operation for this scheme is to open a connection
- using the Web Socket protocol.</dd>
+ using the WebSocket protocol.</dd>
<dt>Encoding considerations.</dt>
<dd>
@@ -77353,7 +77970,7 @@
</dd>
<dt>Applications/protocols that use this URI scheme name.</dt>
- <dd>Web Socket protocol.</dd>
+ <dd>WebSocket protocol.</dd>
<dt>Interoperability considerations.</dt>
<dd>None.</dd>
@@ -77375,7 +77992,7 @@
<h6>Registration of <code title="">wss:</code> scheme</h6>
- <p>A <code title="">wss:</code> URL identifies a Web Socket server
+ <p>A <code title="">wss:</code> URL identifies a WebSocket server
and resource name, and indicates that traffic over that connection
is to be encrypted.</p>
@@ -77404,7 +78021,7 @@
<dt>URI scheme semantics.</dt>
<dd>The only operation for this scheme is to open a connection
- using the Web Socket protocol, encrypted using TLS.</dd>
+ using the WebSocket protocol, encrypted using TLS.</dd>
<dt>Encoding considerations.</dt>
<dd>
@@ -77427,7 +78044,7 @@
</dd>
<dt>Applications/protocols that use this URI scheme name.</dt>
- <dd>Web Socket protocol over TLS.</dd>
+ <dd>WebSocket protocol over TLS.</dd>
<dt>Interoperability considerations.</dt>
<dd>None.</dd>
@@ -77467,19 +78084,70 @@
- <h6><dfn title="http-websocket-origin"><code>WebSocket-Origin</code></dfn></h6>
+ <h6><dfn title="http-sec-websocket-key1"><code>Sec-WebSocket-Key1</code></dfn> and <dfn title="http-sec-websocket-key2"><code>Sec-WebSocket-Key2</code></dfn></h6>
+ <p>This section describes two header fields for registration in the
+ Permanent Message Header Field Registry. <a
+ href="#refsRFC3864">[RFC3864]</a></p>
+
+ <dl>
+ <dt>Header field name</dt>
+ <dd>Sec-WebSocket-Key1</dd>
+ <dt>Applicable protocol</dt>
+ <dd>http</dd>
+ <dt>Status</dt>
+ <dd>reserved; do not use outside WebSocket handshake</dd>
+ <dt>Author/Change controller</dt>
+ <dd>IETF</dd>
+ <dt>Specification document(s)</dt>
+ <dd>
+ This document is the relevant specification.
+ </dd>
+ <dt>Related information</dt>
+ <dd>None.</dd>
+ </dl>
+
+ <dl>
+ <dt>Header field name</dt>
+ <dd>Sec-WebSocket-Key2</dd>
+ <dt>Applicable protocol</dt>
+ <dd>http</dd>
+ <dt>Status</dt>
+ <dd>reserved; do not use outside WebSocket handshake</dd>
+ <dt>Author/Change controller</dt>
+ <dd>IETF</dd>
+ <dt>Specification document(s)</dt>
+ <dd>
+ This document is the relevant specification.
+ </dd>
+ <dt>Related information</dt>
+ <dd>None.</dd>
+ </dl>
+
+ <p>The <code
+ title="http-sec-websocket-key1">Sec-WebSocket-Key1</code> and <code
+ title="http-sec-websocket-key2">Sec-WebSocket-Key2</code> 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.</p>
+
+
+ <h6><dfn title="http-sec-websocket-location"><code>Sec-WebSocket-Location</code></dfn></h6>
+
<p>This section describes a header field for registration in the
Permanent Message Header Field Registry. <a
href="#refsRFC3864">[RFC3864]</a></p>
<dl>
<dt>Header field name</dt>
- <dd>WebSocket-Origin</dd>
+ <dd>Sec-WebSocket-Location</dd>
<dt>Applicable protocol</dt>
<dd>http</dd>
<dt>Status</dt>
- <dd>reserved; do not use outside Web Socket handshake</dd>
+ <dd>reserved; do not use outside WebSocket handshake</dd>
<dt>Author/Change controller</dt>
<dd>IETF</dd>
<dt>Specification document(s)</dt>
@@ -77490,14 +78158,17 @@
<dd>None.</dd>
</dl>
- <p>The <code>WebSocket-Origin</code> header is used in the Web
- Socket handshake. It is sent from the server to the client to
- confirm the <span>origin</span> 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.</p>
+ <p>The <code
+ title="http-sec-websocket-location">Sec-WebSocket-Location</code>
+ header is used in the WebSocket handshake. It is sent from the
+ server to the client to confirm the <span>URL</span> 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.</p>
- <h6><dfn title="http-websocket-protocol"><code>WebSocket-Protocol</code></dfn></h6>
+ <h6><dfn title="http-sec-websocket-origin"><code>Sec-WebSocket-Origin</code></dfn></h6>
<p>This section describes a header field for registration in the
Permanent Message Header Field Registry. <a
@@ -77505,11 +78176,11 @@
<dl>
<dt>Header field name</dt>
- <dd>WebSocket-Protocol</dd>
+ <dd>Sec-WebSocket-Origin</dd>
<dt>Applicable protocol</dt>
<dd>http</dd>
<dt>Status</dt>
- <dd>reserved; do not use outside Web Socket handshake</dd>
+ <dd>reserved; do not use outside WebSocket handshake</dd>
<dt>Author/Change controller</dt>
<dd>IETF</dd>
<dt>Specification document(s)</dt>
@@ -77520,14 +78191,16 @@
<dd>None.</dd>
</dl>
- <p>The <code>WebSocket-Protocol</code> header is used in the Web
- Socket 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.</p>
+ <p>The <code
+ title="http-sec-websocket-origin">Sec-WebSocket-Origin</code> header
+ is used in the WebSocket handshake. It is sent from the server to
+ the client to confirm the <span>origin</span> 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.</p>
- <h6><dfn title="http-websocket-location"><code>WebSocket-Location</code></dfn></h6>
+ <h6><dfn title="http-sec-websocket-protocol"><code>Sec-WebSocket-Protocol</code></dfn></h6>
<p>This section describes a header field for registration in the
Permanent Message Header Field Registry. <a
@@ -77535,11 +78208,11 @@
<dl>
<dt>Header field name</dt>
- <dd>WebSocket-Location</dd>
+ <dd>Sec-WebSocket-Protocol</dd>
<dt>Applicable protocol</dt>
<dd>http</dd>
<dt>Status</dt>
- <dd>reserved; do not use outside Web Socket handshake</dd>
+ <dd>reserved; do not use outside WebSocket handshake</dd>
<dt>Author/Change controller</dt>
<dd>IETF</dd>
<dt>Specification document(s)</dt>
@@ -77550,24 +78223,25 @@
<dd>None.</dd>
</dl>
- <p>The <code>WebSocket-Location</code> header is used in the Web
- Socket handshake. It is sent from the server to the client to
- confirm the <span>URL</span> 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.</p>
+ <p>The <code
+ title="http-sec-websocket-protocol">Sec-WebSocket-Protocol</code>
+ 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.</p>
- <h5>Using the Web Socket protocol from other specifications</h5>
+ <h5>Using the WebSocket protocol from other specifications</h5>
- <p>The Web Socket protocol is intended to be used by another
+ <p>The WebSocket protocol is intended to be used by another
specification to provide a generic mechanism for dynamic
author-defined content, e.g. in a specification defining a scripted
API.</p>
- <p>Such a specification first needs to "<span>establish a Web Socket
+ <p>Such a specification first needs to "<span>establish a WebSocket
connection</span>", providing that algorithm with:</p>
<ul>
@@ -77586,41 +78260,41 @@
href="#refsORIGIN">[ORIGIN]</a></li>
<li>Optionally a string identifying a <span>protocol</span> that is
- to be layered over the Web Socket connection.</li>
+ to be layered over the WebSocket connection.</li>
</ul>
<p>The <var title="">host</var>, <var title="">port</var>, <var
title="">resource name</var>, and <var title="">secure</var> flag
are usually obtained from a <span>URL</span> using the steps to
- <span>parse a Web Socket URL's components</span>. These steps fail
- if the URL does not specify a Web Socket.</p>
+ <span>parse a WebSocket URL's components</span>. These steps fail
+ if the URL does not specify a WebSocket.</p>
<p>If a connection can be established, then it is said that the
- "<span>Web Socket connection is established</span>".</p>
+ "<span>WebSocket connection is established</span>".</p>
<p>If at any time the connection is to be closed, then the
- specification needs to use the "<span>close the Web Socket
+ specification needs to use the "<span>close the WebSocket
connection</span>" algorithm.</p>
<p>When the connection is closed, for any reason including failure
to establish the connection in the first place, it is said that the
- "<span>Web Socket connection is closed</span>".</p>
+ "<span>WebSocket connection is closed</span>".</p>
<p>While a connection is open, the specification will need to handle
- the cases when "<span>a Web Socket message has been received</span>"
+ the cases when "<span>a WebSocket message has been received</span>"
with text <var title="">data</var>.</p>
<p>To send some text <var title="">data</var> to an open connection,
the specification needs to "<span>send <var title="">data</var>
- using the Web Socket</span>".</p>
+ using the WebSocket</span>".</p>
<!--END complete-->
<h5>Acknowledgements</h5>
- <p>The Web Socket protocol is the result of many years of
+ <p>The WebSocket protocol is the result of many years of
development, and as such hundreds of people have contributed to the
specification during its lifetime. Unfortunately, since the
specification started as nothing but a minor section of the larger
@@ -99785,6 +100459,10 @@
Names - Concepts and Facilities</a></cite>, P. Mockapetris. IETF,
November 1987.</dd>
+ <dt id="refsRFC1321">[RFC1321]</dt>
+ <dd><cite><a href="http://www.ietf.org/rfc/rfc1321.txt">The MD5
+ Message-Digest Algorithm</a></cite>, R. Rivest. IETF.</dd>
+
<dt id="refsRFC1345">[RFC1345]</dt>
<dd><cite><a href="http://www.ietf.org/rfc/rfc1345.txt">Character Mnemonics
and Character Sets</a></cite>, K. Simonsen. IETF.</dd>
@@ -100059,10 +100737,10 @@
<dt id="refsWEBSOCKET">[WEBSOCKET]</dt>
<!--
- <dd><cite><a href="http://www.w3.org/TR/websockets/">The Web Sockets
+ <dd><cite><a href="http://www.w3.org/TR/websockets/">The WebSocket
API</a></cite>, I. Hickson. W3C.</dd>
-->
- <dd><cite><a href="http://dev.w3.org/html5/websockets/">The Web Sockets
+ <dd><cite><a href="http://dev.w3.org/html5/websockets/">The WebSocket
API</a></cite>, I. Hickson. W3C.</dd>
<dt id="refsWEBSQL">[WEBSQL]</dt>
@@ -100105,10 +100783,10 @@
<dt id="refsWSAPI">[WSAPI]</dt>
<!--
- <dd><cite><a href="http://www.w3.org/TR/websockets/">Web Sockets
+ <dd><cite><a href="http://www.w3.org/TR/websockets/">WebSocket
API</a></cite>, I. Hickson. W3C.</dd>
-->
- <dd><cite><a href="http://dev.w3.org/html5/websockets/">Web Sockets
+ <dd><cite><a href="http://dev.w3.org/html5/websockets/">WebSocket
API</a></cite>, I. Hickson. W3C.</dd>
<dt id="refsX121">[X121]</dt>
More information about the Commit-Watchers
mailing list