[html5] r4448 - [e] (0) Try to clarify the way the server-side of the WebSocket protocol works.
whatwg at whatwg.org
whatwg at whatwg.org
Wed Dec 16 09:12:49 PST 2009
Author: ianh
Date: 2009-12-16 09:12:47 -0800 (Wed, 16 Dec 2009)
New Revision: 4448
Modified:
complete.html
source
Log:
[e] (0) Try to clarify the way the server-side of the WebSocket protocol works.
Modified: complete.html
===================================================================
--- complete.html 2009-12-16 16:46:40 UTC (rev 4447)
+++ complete.html 2009-12-16 17:12:47 UTC (rev 4448)
@@ -950,8 +950,8 @@
<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="#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="#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=#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>
@@ -66833,113 +66833,18 @@
<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="reading-the-client's-handshake"><span class=secno>10.3.4.4.1 </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>
-
- </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. The value must be interpreted as UTF-8.</p>
-
- </dd>
-
- <dt>Origin (bytes 4F 72 69 67 69 6E; always the fourth name-value pair)</dt> <!-- http-origin -->
-
- <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
- 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>
-
- </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 -->
-
- <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>
-
- </dd>
-
- <dt>Other fields</dt>
-
- <dd>
-
- <p>Other fields can be used, such as "<code title="">Cookie</code>"<!--(v2-ws-auth) or
- "<code>Authorization</code>"-->, for authentication
- purposes. Their semantics are equivalent to the semantics of the
- HTTP headers with the same names.</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>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>
+ <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
- 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>
+ (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>
<p>If the server supports encryption, then the server must perform a
TLS handshake over the connection before sending the server
@@ -67033,6 +66938,109 @@
the four bytes 0x0D 0x0A 0x0D 0x0A to the client.</p>
+ <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>
+
+ </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. The value must be interpreted as UTF-8.</p>
+
+ </dd>
+
+ <dt>Origin (bytes 4F 72 69 67 69 6E; always the fourth name-value pair)</dt> <!-- http-origin -->
+
+ <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
+ 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>
+
+ </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 -->
+
+ <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>
+
+ </dd>
+
+ <dt>Other fields</dt>
+
+ <dd>
+
+ <p>Other fields can be used, such as "<code title="">Cookie</code>"<!--(v2-ws-auth) or
+ "<code>Authorization</code>"-->, for authentication
+ purposes. Their semantics are equivalent to the semantics of the
+ HTTP headers with the same names.</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>Any fields that lack the colon-space separator must at a minimum
+ be discarded and may cause the server to disconnect.</p>
+
+ <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>
+
+
<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
Modified: source
===================================================================
--- source 2009-12-16 16:46:40 UTC (rev 4447)
+++ source 2009-12-16 17:12:47 UTC (rev 4448)
@@ -76235,107 +76235,6 @@
<h5>Server-side requirements</h5>
<p><i>This section only applies to servers.</i></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>
-
- <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. The value must be interpreted as UTF-8.</p>
-
- </dd>
-
- <dt>Origin (bytes 4F 72 69 67 69 6E; always the fourth name-value pair)</dt> <!-- http-origin -->
-
- <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
- 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>
-
- </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 -->
-
- <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>
-
- </dd>
-
- <dt>Other fields</dt>
-
- <dd>
-
- <p>Other fields can be used, such as "<code
- title="">Cookie</code>"<!--(v2-ws-auth) or
- "<code>Authorization</code>"-->, for authentication
- purposes. Their semantics are equivalent to the semantics of the
- HTTP headers with the same names.</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>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>
@@ -76343,10 +76242,11 @@
<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
- 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>
+ (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>
<p>If the server supports encryption, then the server must perform a
TLS handshake over the connection before sending the server
@@ -76446,6 +76346,114 @@
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>
+
+ <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. The value must be interpreted as UTF-8.</p>
+
+ </dd>
+
+ <dt>Origin (bytes 4F 72 69 67 69 6E; always the fourth name-value pair)</dt> <!-- http-origin -->
+
+ <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
+ 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>
+
+ </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 -->
+
+ <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>
+
+ </dd>
+
+ <dt>Other fields</dt>
+
+ <dd>
+
+ <p>Other fields can be used, such as "<code
+ title="">Cookie</code>"<!--(v2-ws-auth) or
+ "<code>Authorization</code>"-->, for authentication
+ purposes. Their semantics are equivalent to the semantics of the
+ HTTP headers with the same names.</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>Any fields that lack the colon-space separator must at a minimum
+ be discarded and may cause the server to disconnect.</p>
+
+ <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>
+
+
<h6 id="ws-sd-framing">Data framing</h6>
<p>The server must run through the following steps to process the
More information about the Commit-Watchers
mailing list