[html5] r4284 - [e] (0) More details on the headers in WebSocket.
whatwg at whatwg.org
whatwg at whatwg.org
Thu Oct 22 20:45:28 PDT 2009
Author: ianh
Date: 2009-10-22 20:45:26 -0700 (Thu, 22 Oct 2009)
New Revision: 4284
Modified:
complete.html
source
Log:
[e] (0) More details on the headers in WebSocket.
Modified: complete.html
===================================================================
--- complete.html 2009-10-23 03:20:31 UTC (rev 4283)
+++ complete.html 2009-10-23 03:45:26 UTC (rev 4284)
@@ -67729,8 +67729,15 @@
</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,8 +67755,15 @@
</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,8 +67781,38 @@
</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
author-defined content, e.g. in a specification defining a scripted
Modified: source
===================================================================
--- source 2009-10-23 03:20:31 UTC (rev 4283)
+++ source 2009-10-23 03:45:26 UTC (rev 4284)
@@ -76169,7 +76169,13 @@
<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>
<p>This section describes a header field for registration in the
@@ -76193,7 +76199,13 @@
<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>
<p>This section describes a header field for registration in the
@@ -76217,9 +76229,38 @@
<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>
+
+
+
+
<h5>Using the Web Socket protocol from other specifications</h5>
<p>The Web Socket protocol is intended to be used by another
More information about the Commit-Watchers
mailing list