[giow] (0) Block redirects in WebSockets

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

complete.html

@@ -239,7 +239,7 @@
 
   <header class=head id=head><p><a class=logo href=http://www.whatwg.org/><img alt=WHATWG height=101 src=/images/logo width=101></a></p>
    <hgroup><h1>Web Applications 1.0</h1>
-    <h2 class="no-num no-toc">Living Standard &mdash; Last Updated 23 May 2011</h2>
+    <h2 class="no-num no-toc">Living Standard &mdash; Last Updated 24 May 2011</h2>
    </hgroup><dl><dt>Multiple-page version:</dt>
     <dd><a href=http://www.whatwg.org/specs/web-apps/current-work/complete/>http://www.whatwg.org/specs/web-apps/current-work/complete/</a></dd>
     <dt>One-page version:</dt>
@@ -78898,6 +78898,21 @@ <h4 id=the-websocket-interface><span class=secno>11.3.2 </span>The <code><a href
     the resource name, with <var title="">protocols</var> as the
     (possibly empty) list of protocols, and with the <var title="">defer cookies</var> flag set. <a href=#refsWSP>[WSP]</a></p>
 
+    <p>When the user agent <i>validates the server's response</i> during
+    the "<span>establish a WebSocket connection</span>" algorithm, if
+    the status code received from the server is not 101 (e.g. it is a
+    redirect), the user agent must <span>fail the websocket
+    connection</span>.</p>
+
+    <p class=warning>Following HTTP procedures here could introduce
+    serious security problems in a Web browser context. For example,
+    consider a host with a WebSocket server at one path and an open
+    HTTP redirector at another. Suddenly, any script that can be given
+    a particular WebSocket URL can be tricked into communicating to
+    (and potentially sharing secrets with) any host on the Internet,
+    even if the script checks that the URL has the right hostname.</p>
+    <!-- http://www.ietf.org/mail-archive/web/hybi/current/msg06951.html -->
+
     <p class=note>If the "<span>establish a WebSocket
     connection</span>" algorithm fails, it triggers the "<span>fail
     the WebSocket connection</span>" algorithm, which then invokes
@@ -79198,7 +79213,7 @@ <h5 id=garbage-collection-1><span class=secno>11.3.3.2 </span>Garbage collection
   WebSocket connection</span>. <a href=#refsWSP>[WSP]</a></p>
 
 
-  
+
 
   </div><!--data-component-->
 

source

@@ -89547,6 +89547,21 @@ interface <dfn>WebSocket</dfn> {
     title="">defer cookies</var> flag set. <a
     href="#refsWSP">[WSP]</a></p>
 
+    <p>When the user agent <i>validates the server's response</i> during
+    the "<span>establish a WebSocket connection</span>" algorithm, if
+    the status code received from the server is not 101 (e.g. it is a
+    redirect), the user agent must <span>fail the websocket
+    connection</span>.</p>
+
+    <p class="warning">Following HTTP procedures here could introduce
+    serious security problems in a Web browser context. For example,
+    consider a host with a WebSocket server at one path and an open
+    HTTP redirector at another. Suddenly, any script that can be given
+    a particular WebSocket URL can be tricked into communicating to
+    (and potentially sharing secrets with) any host on the Internet,
+    even if the script checks that the URL has the right hostname.</p>
+    <!-- http://www.ietf.org/mail-archive/web/hybi/current/msg06951.html -->
+
     <p class="note">If the "<span>establish a WebSocket
     connection</span>" algorithm fails, it triggers the "<span>fail
     the WebSocket connection</span>" algorithm, which then invokes
@@ -89928,7 +89943,7 @@ Once we have the cookies back:
   WebSocket connection</span>. <a href="#refsWSP">[WSP]</a></p>
 
 
-  <!--END websocket-api-->
+<!--END websocket-api-->
 
   </div><!--data-component-->