Skip to content

Commit

Permalink
[e] (0) Try to clarify the way the server-side of the WebSocket proto…
Browse files Browse the repository at this point in the history 
…col works.

git-svn-id: http://svn.whatwg.org/webapps@4448 340c8d12-0b0e-0410-8428-c7bf67bfef74
  • Loading branch information
@Hixie
Hixie committed Dec 16, 2009
1 parent 519fb6f commit 0b578b5
Show file tree
Hide file tree
Showing 2 changed files with 224 additions and 208 deletions.
214 changes: 111 additions & 103 deletions complete.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -950,8 +950,8 @@ <h2 class="no-num no-toc" id=status>Status of this document</h2>
<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>
Expand Down Expand Up @@ -66833,113 +66833,18 @@ <h6 id=handling-errors-in-utf-8><span class=secno>10.3.4.3.4 </span>Handling err
<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
Expand Down Expand Up @@ -67033,6 +66938,109 @@ <h6 id="sending-the-server's-handshake"><span class=secno>10.3.4.4.2 </span>Send
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
Expand Down

0 comments on commit 0b578b5

Please sign in to comment.