[html5] r4421 - [t] (0) Correct the description of how to parse the client's handshake to includ [...]

[whatwg at whatwg.org]

Author: ianh
Date: 2009-12-09 04:54:47 -0800 (Wed, 09 Dec 2009)
New Revision: 4421

Modified:
   complete.html
   source
Log:
[t] (0) Correct the description of how to parse the client's handshake to include the invariant headers.

Modified: complete.html
===================================================================
--- complete.html	2009-12-09 12:40:47 UTC (rev 4420)
+++ complete.html	2009-12-09 12:54:47 UTC (rev 4421)
@@ -66723,19 +66723,37 @@
   value. The possible names, and the meaning of their corresponding
   values, are as follows:</p>
 
-  <dl><dt>Host (bytes 48 6F 73 74; always the first name-value pair)</dt>
+  <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>
+
+   </dd>
+
+   <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>
+
+   <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
     to virtual hosting environments, where one server might serve
     multiple hosts, and might therefore want to return different
-    data.</p>
+    data. The value must be interpreted as UTF-8.</p>
 
    </dd>
 
-   <dt>Origin (bytes 4F 72 69 67 69 6E; always the second name-value pair)</dt> <!-- http-origin -->
+   <dt>Origin (bytes 4F 72 69 67 69 6E; always the fourth name-value pair)</dt> <!-- http-origin -->
 
    <dd>
 
@@ -66745,17 +66763,18 @@
     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.</p>
+    connection. The value must be interpreted as UTF-8.</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 third name-value pair)</dt> <!-- http-websocket-protocol -->
+   <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 -->
 
    <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.</p>
+    supports multiple protocols or protocol versions. The value must
+    be interpreted as UTF-8.</p>
 
    </dd>
 
@@ -66825,7 +66844,7 @@
 
    <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 first
+   from the client's handshake, specifically from the "Host"
    field.</dd>
 
    <dt><var title="">secure flag</var><dt>

Modified: source
===================================================================
--- source	2009-12-09 12:40:47 UTC (rev 4420)
+++ source	2009-12-09 12:54:47 UTC (rev 4421)
@@ -76110,19 +76110,37 @@
 
   <dl>
 
-   <dt>Host (bytes 48 6F 73 74; always the first name-value pair)</dt>
+   <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>
+
+   </dd>
+
+   <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>
+
+   <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
     to virtual hosting environments, where one server might serve
     multiple hosts, and might therefore want to return different
-    data.</p>
+    data. The value must be interpreted as UTF-8.</p>
 
    </dd>
 
-   <dt>Origin (bytes 4F 72 69 67 69 6E; always the second name-value pair)</dt> <!-- http-origin -->
+   <dt>Origin (bytes 4F 72 69 67 69 6E; always the fourth name-value pair)</dt> <!-- http-origin -->
 
    <dd>
 
@@ -76132,17 +76150,18 @@
     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.</p>
+    connection. The value must be interpreted as UTF-8.</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 third name-value pair)</dt> <!-- http-websocket-protocol -->
+   <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 -->
 
    <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.</p>
+    supports multiple protocols or protocol versions. The value must
+    be interpreted as UTF-8.</p>
 
    </dd>
 
@@ -76218,7 +76237,7 @@
 
    <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 first
+   from the client's handshake, specifically from the "Host"
    field.</dd>
 
    <dt><var title="">secure flag</var><dt>