Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocketprotocol-01.txt

Ian Fette (イアンフェッティ) <ifette@google.com> Fri, 24 September 2010 21:13 UTC

Return-Path: <ifette@google.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D2133A691F for <hybi@core3.amsl.com>; Fri, 24 Sep 2010 14:13:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.094
X-Spam-Level:
X-Spam-Status: No, score=-104.094 tagged_above=-999 required=5 tests=[AWL=0.982, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNcd77Nsotjr for <hybi@core3.amsl.com>; Fri, 24 Sep 2010 14:13:37 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 4E45E3A6A45 for <hybi@ietf.org>; Fri, 24 Sep 2010 14:13:36 -0700 (PDT)
Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id o8OLE7IH007690 for <hybi@ietf.org>; Fri, 24 Sep 2010 14:14:07 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1285362848; bh=hnTttOJYghsIodIa7bm629tlEuE=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=nzapGtkF6CBYU9vrw1ADHiFTCU7n0zXpsUuWeAwtiYDvbYfUngOj6INkbZC4XmdxP 6sKZyTHGiM9+Zh3spAAsA==
Received: from gxk8 (gxk8.prod.google.com [10.202.11.8]) by wpaz21.hot.corp.google.com with ESMTP id o8OLE5nU003054 for <hybi@ietf.org>; Fri, 24 Sep 2010 14:14:05 -0700
Received: by gxk8 with SMTP id 8so1572403gxk.27 for <hybi@ietf.org>; Fri, 24 Sep 2010 14:14:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=TdEkkuWYPq7LrdCE5r0JVTBPMwkEh65NFqQFk6m5MJY=; b=YLPSS4dRkdzG9rfyND1Qcds2dFkXV7jbe8bF/5umhpKB38zMuYLMbB3vw0RdAaCH8/ aJ9yZqoxoreyp72o8jyw==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=bg5HuVZCEYeF/8fU8psrCIqDDZTdSqU3O+EF2OVdHrAqgmfFcrlXFz7kKacA7wARPf Wni6Ici4c4T8wo32GYFA==
MIME-Version: 1.0
Received: by 10.151.110.9 with SMTP id n9mr5386809ybm.188.1285362844689; Fri, 24 Sep 2010 14:14:04 -0700 (PDT)
Received: by 10.150.96.11 with HTTP; Fri, 24 Sep 2010 14:14:04 -0700 (PDT)
In-Reply-To: <op.vif8o0stidj3kv@simon-pieterss-macbook.local>
References: <20100901224502.0519B3A687C@core3.amsl.com> <AANLkTi=u3t6ayoKQSs8oZu=gdaU5k_+UuKjSQfg+3ATb@mail.gmail.com> <op.vieipeemidj3kv@simon-pieterss-macbook.local> <AANLkTi=_1zd9G=6jGU5m+spxCxNh511juE64bWzLpaVu@mail.gmail.com> <op.vif8o0stidj3kv@simon-pieterss-macbook.local>
Date: Fri, 24 Sep 2010 14:14:04 -0700
Message-ID: <AANLkTikc0Pq2WD68PhTvUd=t3PNB56T3JC6t-NQrsiPE@mail.gmail.com>
From: "Ian Fette (イアンフェッティ)" <ifette@google.com>
To: Simon Pieters <simonp@opera.com>
Content-Type: multipart/alternative; boundary="001517574664c3f665049107dbb7"
X-System-Of-Record: true
Cc: hybi@ietf.org
Subject: Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocketprotocol-01.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: ifette@google.com
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Sep 2010 21:13:42 -0000

2010/9/3 Simon Pieters <simonp@opera.com>

> On Thu, 02 Sep 2010 18:24:58 +0200, Ian Fette (イアンフェッティ) <
> ifette@google.com> wrote:
>
>  Some of those changes were in response to feedback from me (mostly sent to
>>> whatwg). I was happy with the changes Ian Hickson made. What's the plan?
>>> Is
>>> there something I should do if I want those changes in?
>>>
>>> Cheers,
>>>
>>>
>> IMO best thing would be to send an email to this list explaining what the
>> change is, and why it was needed. I don't want to lose these changes, I
>> just
>> want to make sure they are discussed on this list.
>>
>
> Ok. Here are the changes I could find since -00 and associated emails/bugs
> ignoring things that are moot with -01 and things that IIRC were discussed
> on hybi:
>
>
Revisions below refer to revisions of
http://svn.tools.ietf.org/svn/wg/hybi/websocket/draft-ietf-hybi-thewebsocketprotocol.xml


> http://html5.org/tools/web-apps-tracker?from=4893&to=4894
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=9149


This change as best as I can tell is already in -01


>
>
> http://html5.org/tools/web-apps-tracker?from=5169&to=5170
> https://bugzilla.mozilla.org/show_bug.cgi?id=472529#c180 (can't find the
> relevant email)
>
>
Committed as r15


> http://html5.org/tools/web-apps-tracker?from=5174&to=5189
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-July/027245.html
>
>
As best as I can tell, the below corresponds to the part of the source file
that was the JavaScript API, not the protocol. This text is not present in
the HyBi document. I have not incorporated this change.
--- source (revision 5174)
+++ source (revision 5189)
@@ -80897,8 +80897,9 @@
     title="">host</var>, on port <var title="">port</var> (if one was
     specified), from <var title="">origin</var>, with the flag <var
     title="">secure</var>, with <var title="">resource name</var> as
-    the resource name, and with <var title="">protocols</var> as the
-    (possibly empty) list of protocols.</p>
+    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.</p>


Ditto with the below:
     <p class="note">If the "<span>establish a WebSocket
     connection</span>" algorithm fails, it triggers the "<span>fail
@@ -81137,10 +81138,13 @@
   <p>When the <i>WebSocket connection is established</i>, the user
   agent must <span>queue a task</span> to first change the <code
   title="dom-WebSocket-readyState">readyState</code> attribute's value
-  to <code title="dom-WebSocket-OPEN">OPEN</code> (1); then change the
-  <code title="dom-WebSocket-protocol">protocol</code> attribute's
-  value to the <span>selected WebSocket subprotocol</span>, if there
-  is one; and then <span>fire a simple event</span> named <code
+  to <code title="dom-WebSocket-OPEN">OPEN</code> (1); <span>apply the
+  cookies</span> that were collected in the <var title="">list of
+  cookies</var> when the <span title="WebSocket connection is
+  established">connection was established</span>; change the <code
+  title="dom-WebSocket-protocol">protocol</code> attribute's value to
+  the <span>selected WebSocket subprotocol</span>, if there is one;
+  and then <span>fire a simple event</span> named <code
   title="event-open">open</code> at the <code>WebSocket</code>
   object.</p>

Again, the below seems to be in the HTML/JS api, not the protocol, so I have
not incorporated any of the below.
@@ -81215,10 +81219,40 @@

   <h5>Garbage collection</h5>

-  <p>A <code>WebSocket</code> object with an open connection must not
-  be garbage collected if there are any event listeners registered for
-  <code title="event-message">message</code> events.</p>
+  <p>A <code>WebSocket</code> object whose <code
+  title="dom-WebSocket-readyState">readyState</code> attribute's value
+  was set to <code title="dom-WebSocket-CONNECTING">CONNECTING</code>
+  (0) as of the last time the <span>event loop</span> started
+  executing a <span title="concept-task">task</span> must not be
+  garbage collected if there are any event listeners registered for
+  <code title="event-open">open</code> events, <code
+  title="event-message">message</code> events, <code
+  title="event-error">error</code> events, or <code
+  title="event-close">close</code> events.</p>

+  <p>A <code>WebSocket</code> object whose <code
+  title="dom-WebSocket-readyState">readyState</code> attribute's value
+  was set to <code title="dom-WebSocket-OPEN">OPEN</code> (1) as of
+  the last time the <span>event loop</span> started executing a <span
+  title="concept-task">task</span> must not be garbage collected if
+  there are any event listeners registered for <code
+  title="event-message">message</code> events, <code
+  title="event-error">error</code> events, or <code
+  title="event-close">close</code> events.</p>
+
+  <p>A <code>WebSocket</code> object whose <code
+  title="dom-WebSocket-readyState">readyState</code> attribute's value
+  was set to <code title="dom-WebSocket-CLOSING">CLOSING</code> (2) as
+  of the last time the <span>event loop</span> started executing a
+  <span title="concept-task">task</span> must not be garbage collected
+  if there are any event listeners registered for <code
+  title="event-close">close</code> events.</p>
+
+  <p>A <code>WebSocket</code> object with <span title="WebSocket
+  connection is established">an established connection</span> that has
+  data queued to be transmitted to the network must not be garbage
+  collected.</p>
+
   <p>If a <code>WebSocket</code> object is garbage collected while its
   connection is still open, the user agent must <span>close the
   WebSocket connection</span>.</p>

Committed as r16
@@ -81540,7 +81574,7 @@

   <p>The third piece of information is given after the fields, in the
   last eight bytes of the handshake, expressed here as they would be
-  seen if interpreted as ASCII:</p>
+  seen if interpreted as UTF-8:</p>

   <pre>Tm[K T2u</pre>

Also in r16
@@ -81597,7 +81631,7 @@
   <em>set</em> cookies, as in HTTP.</p>

   <p>After the fields, the server sends the aforementioned MD5 sum, a
-  16 byte (128 bit) value, shown here as if interpreted as ASCII:</p>
+  16 byte (128 bit) value, shown here as if interpreted as UTF-8:</p>

   <pre>fQJ,fN/4F4!~K~MH</pre>


Incorporated in r17
@@ -81935,6 +81969,13 @@
   <p><i>This section only applies to user agents, not to
   servers.</i></p>

+  <p>User agents running in controlled environments, e.g. browsers on
+  mobile handsets tied to specific carriers, may offload the
+  management of the connection to another agent on the network. In
+  such a situation, the user agent for the purposes of conformance is
+  considered to include both the handset software and any such
+  agents.</p>
+
   <p class="note">This specification doesn't currently define a limit
   to the number of simultaneous connections that a client can
   establish to a server.</p>

Also in r17
@@ -81947,17 +81988,18 @@
   title="">port</var>, from an origin whose <span title="ASCII
   serialization of an origin">ASCII serialization</span> is <var
   title="">origin</var>, with a flag <var title="">secure</var>, with
-  a string giving a <var title="">resource name</var>, and with a
+  a string giving a <var title="">resource name</var>, with a
   (possibly empty) list of strings giving the <var
-  title="">protocols</var>, it must run the following steps. The <var
-  title="">host</var> must be ASCII-only (i.e. it must have been
-  punycode-encoded already if necessary). The <var
-  title="">origin</var> must not contain characters in the range
+  title="">protocols</var>, and optionally with a <var title="">defer
+  cookies</var> flag, it must run the following steps. The <var
+  title="">host</var> must have been punycode-encoded already if
+  necessary (i.e. it does not contain characters above U+007E). The
+  <var title="">origin</var> must not contain characters in the range
   U+0041 to U+005A (i.e. LATIN CAPITAL LETTER A to LATIN CAPITAL
   LETTER Z). The <var title="">resource name</var> string must be a
-  non-empty string of ASCII characters in the range U+0021 to U+007E
-  that starts with a U+002F SOLIDUS character (/). The various strings
-  in <var title="">protocols</var> must all be non-empty strings with
+  non-empty string of characters in the range U+0021 to U+007E that
+  starts with a U+002F SOLIDUS character (/). The various strings in
+  <var title="">protocols</var> must all be non-empty strings with
   characters in the range U+0021 to U+007E, and must all be unique. <a
   href="#refsORIGIN">[ORIGIN]</a></p>

Added as r18
@@ -82194,6 +82236,16 @@
     considered a non-HTTP API for the purpose of cookie
     processing.</p>

+    <p>When one or more HTTP headers are to be added to <var
+    title="">fields</var> for this step, each header must be added
+    separately, and each header must be added as one entry consisting
+    of the header's name in its canonical case, followed by a U+003A
+    COLON character (:) and a U+0020 SPACE character, followed by the
+    value with no use of continuation lines (i.e. containing no U+000A
+    LINE FEED characters).</p>
+
+    <!-- (Cookie headers only use one header for multiple cookies.) -->
+
 <!--(v2-ws-auth)
     <div class="example">

r19
 @@ -82398,6 +82452,7 @@

    </li>

+<!--(removed since the next step is even stricter)
    <li>

     <p>If <var title="">code</var> is not three bytes long, or if any

r19
@@ -82406,6 +82461,7 @@
     these steps.</p>

    </li>
+-->

    <li>

r19
@@ -82380,8 +82432,10 @@

     <p>If <var title="">field</var> is not at least seven bytes long,
     or if the last two bytes aren't 0x0D and 0x0A respectively, or if
-    it does not contain at least two 0x20 bytes, then <span>fail the
-    WebSocket connection</span> and abort these steps.</p>
+    <var title="">field</var> contains any 0x0D bytes other than the
+    penultimate byte, or if <var title="">field</var> does not contain
+    at least two 0x20 bytes, then <span>fail the WebSocket
+    connection</span> and abort these steps.</p>

     <p>User agents may apply a timeout to this step, <spa




r20
@@ -82463,7 +82519,7 @@

     <dl class="switch">

-     <dt>If the byte is 0x0D (ASCII CR)</dt>
+     <dt>If the byte is 0x0D (UTF-8 CR)</dt>

      <dd>If the <var title="">name</var> byte array is empty, then
      jump to the <a href="#ws-ua-fields-processing">fields

r20
@@ -82471,18 +82527,18 @@
      connection</span> and abort these steps.</dd>


-     <dt>If the byte is 0x0A (ASCII LF)</dt>
+     <dt>If the byte is 0x0A (UTF-8 LF)</dt>

      <dd><span>Fail the WebSocket connection</span> and abort these
      steps.</dd>


-     <dt>If the byte is 0x3A (ASCII :)</dt>
+     <dt>If the byte is 0x3A (UTF-8 :)</dt>

      <dd>Move on to the next step.</dd>


-     <dt>If the byte is in the range 0x41 to 0x5A (ASCII A-Z)</dt>
+     <dt>If the byte is in the range 0x41 to 0x5A (UTF-8 A-Z)</dt>

      <dd>Append a byte whose value is the byte's value plus 0x20 to
      the <var title="">name</var> byte array and redo this step for

r20
@@ -82497,8 +82553,8 @@
     </dl>

     <p class="note">This reads a field name, terminated by a colon,
-    converting upper-case ASCII letters to lowercase, and aborting if
-    a stray CR or LF is found.</p>
+    converting upper-case letters in the range A-Z to lowercase, and
+    aborting if a stray CR or LF is found.</p>

    </li>

r20
@@ -82525,17 +82581,17 @@

     <dl class="switch">

-     <dt>If the byte is 0x20 (ASCII space) and <var title="">count</var>
equals 1</dt>
+     <dt>If the byte is 0x20 (UTF-8 space) and <var title="">count</var>
equals 1</dt>

      <dd>Ignore the byte and redo this step for the next byte.</dd>


-     <dt>If the byte is 0x0D (ASCII CR)</dt>
+     <dt>If the byte is 0x0D (UTF-8 CR)</dt>

      <dd>Move on to the next step.</dd>


-     <dt>If the byte is 0x0A (ASCII LF)</dt>
+     <dt>If the byte is 0x0A (UTF-8 LF)</dt>

      <dd><span>Fail the WebSocket connection</span> and abort these
      steps.</dd>

r20
@@ -82558,7 +82614,8 @@
     <p>Read a byte from the server.</p>

     <p>If the connection closes before this byte is received, or if
-    the byte is not a 0x0A byte (ASCII LF), then <span>fail the WebSocket
connection</span> and abort these steps.</p>
+    the byte is not a 0x0A byte (UTF-8 LF), then <span>fail the
+    WebSocket connection</span> and abort these steps.</p>

     <p class="note">This skips past the LF byte of the CRLF after the
     field.</p>

r20
@@ -82587,13 +82644,16 @@
     <p><i>Fields processing</i>: Read a byte from the server.</p>

     <p>If the connection closes before this byte is received, or if
-    the byte is not a 0x0A byte (ASCII LF), then <span>fail the WebSocket
connection</span> and abort these steps.</p>
+    the byte is not a 0x0A byte (UTF-8 LF), then <span>fail the
+    WebSocket connection</span> and abort these steps.</p>

     <p class="note">This skips past the LF byte of the CRLF after the
     blank line after the fields.</p>

    </li>

+   <li><p>Let the <var title="">list of cookies</var> be empty.</p></li>
+
    <li>

     <p>

r21
@@ -82629,9 +82689,9 @@
      <dt>If the entry's name is "<code
      title="http-upgrade">upgrade</code>"</dt>

-     <dd><p>If the value is not exactly equal to the string
-     "WebSocket", then <span>fail the WebSocket connection</span> and
-     abort these steps.</p></dd>
+     <dd><p>If the value, <span>converted to ASCII lowercase</span>,
+     is not exactly equal to the string "websocket", then <span>fail
+     the WebSocket connection</span> and abort these steps.</p></dd>


      <dt>If the entry's name is "<code

r21
@@ -82690,8 +82750,9 @@
      <dd>

       <p>If the relevant specification is supported by the user agent,
-      handle the cookie as defined by the appropriate specification,
-      with the resource being the one with the host <var
+      add the cookie, interpreted as defined by the appropriate
+      specification, to the <var title="">list of cookies</var>, with
+      the resource being the one with the host <var
       title="">host</var>, the port <var title="">port</var>, the path
       (and possibly query parameters) <var title="">resource
       name</var>, and the scheme <code title="">http</code> if <var

r21
@@ -82708,6 +82769,11 @@
       <p>If the relevant specification is not supported by the user
       agent, then the field must be ignored.</p>

+      <p class="note">The cookies added to the <var title="">list of
+      cookies</var> are discarded if the connection fails to be
+      established. Only if and when the connection is established do
+      the cookies actually get applied.</p>
+
      </dd>

***** This text is relating to a portion of the specification
(redirects/location: header) that is no longer in the spec *****
@@ -82764,6 +82830,9 @@
        <li><p>Close the connection if the server has not already done
        so.</p></li>

+       <li><p><span>Apply the cookies</span> in the <var title="">list
+       of cookies</var>.</p></li>
+
        <li><p>Jump back to the first step of the overall algorithm
        (the very top of the handshake).</p></li>

***** ditto -- not in the spec *****
@@ -82794,19 +82863,24 @@
      <dt>If the entry's name is "<code
      title="">www-authenticate</code>"</dt>

-     <dd><p>Obtain credentials in a manner consistent with the
-     requirements for handling the <code>WWW-Authenticate</code>
-     header in HTTP, and then close the connection (if the server has
-     not already done so) and jump back to the step labeled
-     <i>connect</i>, including the relevant authentication headers in
-     the new request.
+     <dd>
+
+      <p><span>Apply the cookies</span> in the <var title="">list of
+      cookies</var>, then obtain credentials in a manner consistent
+      with the requirements for handling the
+      <code>WWW-Authenticate</code> header in HTTP, and then close
+      the connection (if the server has not already done so) and jump
+      back to the step labeled <i>connect</i>, including the relevant
+      authentication headers in the new request.
 --><!--END complete--><!--END epub--><!--
-     <a href="#refsRFC2616">[RFC2616]</a>
+      <a href="#refsRFC2616">[RFC2616]</a>
 --><!--START complete--><!--START epub--><!--END websocket-protocol--><!--
-     <a href="#refsHTTP">[HTTP]</a>
+      <a href="#refsHTTP">[HTTP]</a>
 --><!--START websocket-protocol--><!--
-     </p></dd>
+      </p>

+     </dd>
+
      <dt>Any other name</dt>

      <dd>Ignore it.</dd>

r22
@@ -82847,7 +82921,7 @@

     <p class="example">Using the examples given earlier, this leads to
     the 16 bytes 0x30 0x73 0x74 0x33 0x52 0x6C 0x26 0x71 0x2D 0x32
-    0x5A 0x55 0x5E 0x77 0x65 0x75. In ASCII, these bytes correspond to
+    0x5A 0x55 0x5E 0x77 0x65 0x75. In UTF-8, these bytes correspond to
     the string "0st3Rl&amp;q-2ZU^weu".</p>

    </li>

r22
@@ -82871,17 +82945,58 @@

    </li>

+   <li><p>If the <var title="">defer cookies</var> flag is not set,
+   <span>apply the cookies</span> in the <var title="">list of
+   cookies</var>.</p></li>
+
    <li>

     <p>The <dfn>WebSocket connection is established</dfn>. Now the
     user agent must send and receive to and from the connection as
     described in the next section.</p>

+    <p>If the <var title="">defer cookies</var> flag is set, store the
+    <var title="">list of cookies</var> for use by the component that
+    invoked this algorithm.</p>
+
    </li>

   </ol>

+  <p>Where the algorithm above requires that a user agent <span>fail
+  the WebSocket connection</span>, the user agent may first read an
+  arbitrary number of further bytes from the connection (and then
+  discard them) before actually <span title="fail the WebSocket
+  connection">failing the WebSocket connection</span>. Similarly, if a
+  user agent can show that the bytes read from the connection so far
+  are such that there is no subsequent sequence of bytes that the
+  server can send that would not result in the user agent being
+  required to <span>fail the WebSocket connection</span>, the user
+  agent may immediately <span>fail the WebSocket connection</span>
+  without waiting for those bytes.</p>

+  <p class="note">The previous paragraph is intended to make it
+  conforming for user agents to implement the algorithm in subtlely
+  different ways that are equivalent in all ways except that they
+  terminate the connection at earlier or later points. For example, it
+  enables an implementation to buffer the entire handshake response
+  before checking it, or to verify each field as it is received rather
+  than collecting all the fields and then checking them as a
+  block.</p>
+
+  <p>When the user agent is to <dfn>apply the cookies</dfn> in a <var
+  title="">list of cookies</var>, it must handle each cookie in the
+  <var title="">list of cookies</var> as defined by the appropriate
+  specification.
+<!--END complete--><!--END epub-->
+  <a href="#refsRFC2109">[RFC2109]</a>
+  <a href="#refsRFC2965">[RFC2965]</a>
+<!--START complete--><!--START epub--><!--END websocket-protocol-->
+  <a href="#refsCOOKIES">[COOKIES]</a>
+<!--START websocket-protocol-->
+  </p>
+
+
   <h6>Data framing</h6>

   <p>Once a <span>WebSocket connection is established</span>, the user


**** dead text *****
@@ -82986,8 +83101,14 @@

         </ol>

-        <p>Otherwise, let <var title="">error</var> be true.</p>
+       </li>

+       <li>
+
+        <p>Otherwise, if the <var title="">frame type</var> is not
+        0xFF or if the <var title="">length</var> was not 0, let <var
+        title="">error</var> be true.</p>
+
        </li>

       </ol>

**** dead text *****
@@ -83096,9 +83217,10 @@

   </ol>

-  <p class="note">The closing handshake <span title="the WebSocket
-  closing handshake has finished">finishes</span> once the server
-  returns the 0xFF packet, as described above.</p>
+  <p class="note">If the user agent initiates it, the closing
+  handshake <span title="the WebSocket closing handshake has
+  finished">finishes</span> once the server returns the 0xFF frame, as
+  described above.</p>

   <hr>

r23
@@ -83125,7 +83247,25 @@

   <p><i>This section only applies to servers.</i></p>

+  <p>Servers may offload the management of the connection to other
+  agents on the network, for example load balancers and reverse
+  proxies. In such a situation, the server for the purposes of
+  conformance is considered to include all parts of the server-side
+  infrastructure from the first device to terminate the TCP connection
+  all the way to the server that processes requests and sends
+  responses.</p>

+  <div class="example">
+
+   <p>For example, a data center might have a server that responds to
+   Web Socket requests with an appropriate handshake, and then passes
+   the connection to another server to actually process the data
+   frames. For the purposes of this specification, the "server" is the
+   combination of both computers.</p>
+
+  </div>
+
+
   <h6>Reading the client's opening handshake</h6>

   <p>When a client starts a WebSocket connection, it sends its part of

r24
@@ -83355,7 +83495,10 @@
      requests to multiple hosts (e.g. in a virtual hosting
      environment), then the value should be derived from the client's
      handshake, specifically from the "<code
-     title="http-host">Host</code>" field.</dd>
+     title="http-host">Host</code>" field. The <var
+     title="">host</var> value must be lowercase (not containing
+     characters in the range U+0041 LATIN CAPITAL LETTER A to U+005A
+     LATIN CAPITAL LETTER Z).</dd>

      <dt><var title="">port</var></dt>


r25
@@ -83560,7 +83703,7 @@

     <p class="example">In the example above, this would be the 16
     bytes 0x6E 0x60 0x39 0x65 0x42 0x6B 0x39 0x7A 0x24 0x52 0x38 0x70
-    0x4F 0x74 0x56 0x62, or "n`9eBk9z$R8pOtVb" in ASCII.
+    0x4F 0x74 0x56 0x62, or "n`9eBk9z$R8pOtVb" in UTF-8.

    </li>

r25
@@ -83640,7 +83783,7 @@

    <li>

-    <p>Send two bytes 0x0D 0x0A (ASCII CRLF).</p>
+    <p>Send two bytes 0x0D 0x0A (UTF-8 CRLF).</p>

    </li>


r26
@@ -83655,9 +83798,9 @@
   <p>This completes the server's handshake. If the server finishes
   these steps without <span title="abort the WebSocket
   connection">aborting the WebSocket connection</span>, and if the
-  client does not then <span>fail the connection</span>, then the
-  connection is established and the server may begin and receiving
-  sending data, as described in the next section.</p>
+  client does not then <span>fail the WebSocket connection</span>,
+  then the connection is established and the server may begin and
+  receiving sending data, as described in the next section.</p>


 **** dead text ***
@@ -83801,7 +83944,9 @@
   <hr>

   <p>At any time, the server may decide to terminate the WebSocket
-  connection by running through the following steps:</p>
+  connection by running through the following steps. These steps
+  should be run when the <var title="">client terminated</var> flag is
+  set, if they aren't already running.</p>

   <ol>


*** irrelevant***
@@ -83903,7 +84048,6 @@
   connection</span> arbitrarily.</p>


-
   <h5>Security considerations</h5>

   <p>While this protocol is intended to be used by scripts in Web


http://html5.org/tools/web-apps-tracker?from=5241&to=5244
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-August/027673.html
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-August/027674.html
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-August/027675.html
>
>
Most of this did not apply as it was all framing. I applied the following in
r27

@@ -82946,8 +82937,8 @@
    <li>

     <p>Let <var title="">key<sub>3</sub></var> be a string consisting
-    of eight random bytes (or equivalently, a random 64 bit integer
-    encoded in big-endian order).</p>
+    of eight random bytes (or equivalently, a random 64 bit unsigned
+    integer encoded in big-endian order).</p>

     <p class="example">For example, 0x47 0x30 0x22 0x2D 0x5A 0x3F 0x47
     0x58.</p>



> http://html5.org/tools/web-apps-tracker?from=5287&to=5288



I really want to add this in (NPN), but there has been enough discussion
about the state of NPN and the fact that it's not yet a recommendation that
I am leaving this out for now pending further discussion.


>
> http://html5.org/tools/web-apps-tracker?from=5288&to=5289
> I don't know what this was in response to.
>
>
ditto, pending more NPN discussion.


>
> Let me know if there's a change you'd like discussed here that's not listed
> above and I can try to dig it up.
>
> HTH,
> --
> Simon Pieters
> Opera Software
>