[html5] r4855 - [e] (0) Make some readability changes to the WebSocket protocol descriptions to [...]
whatwg at whatwg.org
whatwg at whatwg.org
Wed Mar 17 16:10:54 PDT 2010
Author: ianh
Date: 2010-03-17 16:10:52 -0700 (Wed, 17 Mar 2010)
New Revision: 4855
Modified:
complete.html
source
Log:
[e] (0) Make some readability changes to the WebSocket protocol descriptions to address some off-list feedback.
Modified: complete.html
===================================================================
--- complete.html 2010-03-17 00:02:41 UTC (rev 4854)
+++ complete.html 2010-03-17 23:10:52 UTC (rev 4855)
@@ -67646,7 +67646,7 @@
handshake appears to HTTP servers to be a regular GET request with
an Upgrade offer:</p>
- <pre>GET /resource HTTP/1.1
+ <pre>GET / HTTP/1.1
Upgrade: WebSocket
Connection: Upgrade</pre>
@@ -67759,7 +67759,7 @@
name, and whether the connection is expected to be encrypted:</p>
<pre>Sec-WebSocket-Origin: http://example.com
-Sec-WebSocket-Location: ws://example.com/demo</pre>
+Sec-WebSocket-Location: ws://example.com/</pre>
<p>These fields are checked by the Web browser when it is acting as
a <code><a href=#websocket>WebSocket</a></code> client for scripted pages. A server that
@@ -68931,8 +68931,21 @@
(i.e. if <var title="">b</var> <i title="">and</i>ed with 0x80
returns 0x80), then return to the step above labeled <a href=#ws-cd-length><i>length</i></a>.</li>
- <li><p>Read <var title="">length</var> bytes.</li>
+ <li>
+ <p>Read <var title="">length</var> bytes.</p>
+
+ <p class=warning>It is possible for a server to (innocently
+ or maliciously) send frames with lengths greater than
+ 2<sup>31</sup> or 2<sup>32</sup> bytes, overflowing a signed
+ or unsigned 32bit integer. User agents may therefore impose
+ implementation-specific limits on the lengths of invalid
+ frames that they will skip; even supporting frames 2GB in
+ length is considered, at the time of writing, as going well
+ above and beyond the call of duty.</p>
+
+ </li>
+
<li><p>Discard the read bytes.</li>
<li>
@@ -68988,15 +69001,8 @@
</ol></dd>
- </dl><p class=warning>User agents may impose implementation-specific
- limits on the lengths of invalid frames that they will skip. In
- particular, it is possible for a server to (innocently or
- maliciously) send frames with lengths greater than 2<sup>31</sup>
- or 2<sup>32</sup> bytes, overflowing a signed or unsigned 32bit
- integer.</p>
+ </dl></li>
- </li>
-
<li>
<p>If <var title="">error</var> is true, then <dfn id=a-websocket-error-has-been-detected>a WebSocket
@@ -69615,26 +69621,30 @@
(i.e. if <var title="">b</var> <i title="">and</i>ed with 0x80
returns 0x80), then return to the step above labeled <a href=#ws-sd-length><i>length</i></a>.</li>
- <li><p>Read <var title="">length</var> bytes.</li>
+ <li>
+ <p>Read <var title="">length</var> bytes.</p>
+
+ <p class=warning>It is possible for a malicious client to send
+ frames with lengths greater than 2<sup>31</sup> or
+ 2<sup>32</sup> bytes, overflowing a signed or unsigned 32bit
+ integer. Servers may therefore impose implementation-specific
+ limits on the lengths of invalid frames that they will skip, if
+ they support skipping such frames at all. If a server cannot
+ correctly skip past a long frame, then the server must abort
+ these steps (discarding all future data), and should either
+ immediately disconnect from the client or set the <var title="">client terminated</var> flag.</p>
+
+ </li>
+
<li><p>Discard the read bytes.</li>
<li><p>If <var title="">type</var> is 0xFF and <var title="">length</var> is 0, then set the <var title="">client
terminated</var> flag and abort these steps. All further data
sent by the client should be discarded.</li>
- </ol><p class=warning>Servers may impose implementation-specific
- limits on the lengths of invalid frames that they will skip. In
- particular, it is possible for a malicious client to send frames
- with lengths greater than 2<sup>31</sup> or 2<sup>32</sup> bytes,
- overflowing a signed or unsigned 32bit integer. If a server cannot
- correctly skip past a long frame, then the server must abort these
- steps (discarding all future data), and should either immediately
- disconnect from the client or set the <var title="">client
- terminated</var> flag.</p>
+ </ol></li>
- </li>
-
<li><p>Return to the step labeled <a href=#ws-sd-frame><i>frame</i></a>.</li>
</ol><hr><p>The server must run through the following steps to send strings
Modified: source
===================================================================
--- source 2010-03-17 00:02:41 UTC (rev 4854)
+++ source 2010-03-17 23:10:52 UTC (rev 4855)
@@ -76040,7 +76040,7 @@
handshake appears to HTTP servers to be a regular GET request with
an Upgrade offer:</p>
- <pre>GET /resource HTTP/1.1
+ <pre>GET / HTTP/1.1
Upgrade: WebSocket
Connection: Upgrade</pre>
@@ -76162,7 +76162,7 @@
name, and whether the connection is expected to be encrypted:</p>
<pre>Sec-WebSocket-Origin: http://example.com
-Sec-WebSocket-Location: ws://example.com/demo</pre>
+Sec-WebSocket-Location: ws://example.com/</pre>
<p>These fields are checked by the Web browser when it is acting as
a <code>WebSocket</code> client for scripted pages. A server that
@@ -77502,8 +77502,21 @@
returns 0x80), then return to the step above labeled <a
href="#ws-cd-length"><i>length</i></a>.</p></li>
- <li><p>Read <var title="">length</var> bytes.</p></li>
+ <li>
+ <p>Read <var title="">length</var> bytes.</p>
+
+ <p class="warning">It is possible for a server to (innocently
+ or maliciously) send frames with lengths greater than
+ 2<sup>31</sup> or 2<sup>32</sup> bytes, overflowing a signed
+ or unsigned 32bit integer. User agents may therefore impose
+ implementation-specific limits on the lengths of invalid
+ frames that they will skip; even supporting frames 2GB in
+ length is considered, at the time of writing, as going well
+ above and beyond the call of duty.</p>
+
+ </li>
+
<li><p>Discard the read bytes.</p></li>
<li>
@@ -77577,13 +77590,6 @@
</dl>
- <p class="warning">User agents may impose implementation-specific
- limits on the lengths of invalid frames that they will skip. In
- particular, it is possible for a server to (innocently or
- maliciously) send frames with lengths greater than 2<sup>31</sup>
- or 2<sup>32</sup> bytes, overflowing a signed or unsigned 32bit
- integer.</p>
-
</li>
<li>
@@ -78279,8 +78285,23 @@
returns 0x80), then return to the step above labeled <a
href="#ws-sd-length"><i>length</i></a>.</p></li>
- <li><p>Read <var title="">length</var> bytes.</p></li>
+ <li>
+ <p>Read <var title="">length</var> bytes.</p>
+
+ <p class="warning">It is possible for a malicious client to send
+ frames with lengths greater than 2<sup>31</sup> or
+ 2<sup>32</sup> bytes, overflowing a signed or unsigned 32bit
+ integer. Servers may therefore impose implementation-specific
+ limits on the lengths of invalid frames that they will skip, if
+ they support skipping such frames at all. If a server cannot
+ correctly skip past a long frame, then the server must abort
+ these steps (discarding all future data), and should either
+ immediately disconnect from the client or set the <var
+ title="">client terminated</var> flag.</p>
+
+ </li>
+
<li><p>Discard the read bytes.</p></li>
<li><p>If <var title="">type</var> is 0xFF and <var
@@ -78290,16 +78311,6 @@
</ol>
- <p class="warning">Servers may impose implementation-specific
- limits on the lengths of invalid frames that they will skip. In
- particular, it is possible for a malicious client to send frames
- with lengths greater than 2<sup>31</sup> or 2<sup>32</sup> bytes,
- overflowing a signed or unsigned 32bit integer. If a server cannot
- correctly skip past a long frame, then the server must abort these
- steps (discarding all future data), and should either immediately
- disconnect from the client or set the <var title="">client
- terminated</var> flag.</p>
-
</li>
<li><p>Return to the step labeled <a
More information about the Commit-Watchers
mailing list