[e] (0) More details on the headers in WebSocket.

git-svn-id: http://svn.whatwg.org/webapps@4284 340c8d12-0b0e-0410-8428-c7bf67bfef74

complete.html

@@ -67729,7 +67729,14 @@ <h6 id=registration-of-ws:-scheme><span class=secno>10.3.4.7.1 </span>Registrati
    </dd>
    <dt>Related information</dt>
    <dd>None.</dd>   
-  </dl><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>
+  </dl><p>The <code>WebSocket-Origin</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-protocol-0><span class=secno>10.3.4.7.5 </span><dfn title=http-websocket-protocol><code>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>
@@ -67748,7 +67755,14 @@ <h6 id=registration-of-ws:-scheme><span class=secno>10.3.4.7.1 </span>Registrati
    </dd>
    <dt>Related information</dt>
    <dd>None.</dd>   
-  </dl><h6 id=websocket-location><span class=secno>10.3.4.7.6 </span><dfn title=http-websocket-location><code>WebSocket-Location</code></dfn></h6>
+  </dl><p>The <code>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>
+
+
+  <h6 id=websocket-location><span class=secno>10.3.4.7.6 </span><dfn title=http-websocket-location><code>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>
@@ -67767,7 +67781,37 @@ <h6 id=registration-of-ws:-scheme><span class=secno>10.3.4.7.1 </span>Registrati
    </dd>
    <dt>Related information</dt>
    <dd>None.</dd>   
-  </dl><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>
+  </dl><p>The <code>WebSocket-Location</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>
+
+  <div class=example>
+
+   <p>For example, consider a server running on port 20000 of a shared
+   virtual host, on behalf of the author of www.example.com, which is
+   hosted on that server. The author of the site hostile.example.net,
+   also hosted on the same server, could write a script to connect to
+   port 20000 on hostile.example.net; if neither the client nor the
+   server verified that all was well, this would connect, and the
+   author of the site hostile.example.net could then use the resources
+   of www.example.com.</p>
+
+   <p>With WebSocket, though, the server responds with a
+   <code>WebSocket-Location</code> header in the handshake, explicitly
+   saying that it is serving <code title="">ws://www.example.com:20000/</code>. The client, expecting
+   (in the case of its use by the hostile author) that the
+   <code>WebSocket-Location</code> be <code title="">ws://hostile.example.net:20000/</code>, would abort the
+   connection.</p>
+
+  </div>
+
+
+
+
+  <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>
 
   <p>The Web Socket protocol is intended to be used by another
   specification to provide a generic mechanism for dynamic

source

@@ -76169,6 +76169,12 @@ multi-origin semantics described in [ORIGIN] applying. (http-origin)
    <dd>None.</dd>   
   </dl>
 
+  <p>The <code>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-protocol"><code>WebSocket-Protocol</code></dfn></h6>
 
@@ -76193,6 +76199,12 @@ multi-origin semantics described in [ORIGIN] applying. (http-origin)
    <dd>None.</dd>   
   </dl>
 
+  <p>The <code>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>
+
 
   <h6><dfn title="http-websocket-location"><code>WebSocket-Location</code></dfn></h6>
 
@@ -76217,6 +76229,35 @@ multi-origin semantics described in [ORIGIN] applying. (http-origin)
    <dd>None.</dd>   
   </dl>
 
+  <p>The <code>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>
+
+  <div class="example">
+
+   <p>For example, consider a server running on port 20000 of a shared
+   virtual host, on behalf of the author of www.example.com, which is
+   hosted on that server. The author of the site hostile.example.net,
+   also hosted on the same server, could write a script to connect to
+   port 20000 on hostile.example.net; if neither the client nor the
+   server verified that all was well, this would connect, and the
+   author of the site hostile.example.net could then use the resources
+   of www.example.com.</p>
+
+   <p>With WebSocket, though, the server responds with a
+   <code>WebSocket-Location</code> header in the handshake, explicitly
+   saying that it is serving <code
+   title="">ws://www.example.com:20000/</code>. The client, expecting
+   (in the case of its use by the hostile author) that the
+   <code>WebSocket-Location</code> be <code
+   title="">ws://hostile.example.net:20000/</code>, would abort the
+   connection.</p>
+
+  </div>
+