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&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 >
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Adam Barth
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… John Tamplin
- [hybi] I-D Action:draft-ietf-hybi-thewebsocketpro… Internet-Drafts
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Ian Fette (イアンフェッティ)
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Greg Wilkins
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Greg Wilkins
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Adam Barth
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… John Tamplin
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Joe Hildebrand
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… John Tamplin
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… John Tamplin
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Adam Barth
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Greg Wilkins
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Greg Wilkins
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… John Tamplin
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Roy T. Fielding
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Ian Fette (イアンフェッティ)
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Gabriel Montenegro
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Willy Tarreau
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Willy Tarreau
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Willy Tarreau
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Willy Tarreau
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Takeshi Yoshino
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Joe Hildebrand
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Willy Tarreau
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Hector Santos
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Hector Santos
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Simon Pieters
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Alexey Melnikov
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… James Graham
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Julian Reschke
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Olli Pettay
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Ian Fette (イアンフェッティ)
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Ian Fette (イアンフェッティ)
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Ian Fette (イアンフェッティ)
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Gabriel Montenegro
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… John Tamplin
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… John Tamplin
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Olli Pettay
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Julian Reschke
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Scott Ferguson
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… John Tamplin
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Ian Fette (イアンフェッティ)
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Ian Fette (イアンフェッティ)
- Re: [hybi] Versioning is a anti-pattern Daniel Stenberg
- Re: [hybi] Versioning is a anti-pattern Tim Bray
- Re: [hybi] Versioning is a anti-pattern John Tamplin
- Re: [hybi] Versioning is a anti-pattern Dave Cridland
- Re: [hybi] Versioning is a anti-pattern Hector Santos
- [hybi] List of (mostly) editorial changes for dra… Patrick McManus
- Re: [hybi] List of (mostly) editorial changes for… John Tamplin
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Willy Tarreau
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Dave Cridland
- Re: [hybi] List of (mostly) editorial changes for… Patrick McManus
- [hybi] Web Socket IP Authentication Hector Santos
- Re: [hybi] Versioning is a anti-pattern David Orchard
- Re: [hybi] Versioning is a anti-pattern Greg Wilkins
- Re: [hybi] Versioning is a anti-pattern James Graham
- Re: [hybi] Versioning is a anti-pattern John Tamplin
- Re: [hybi] Versioning is a anti-pattern Julian Reschke
- Re: [hybi] Web Socket IP Authentication Dave Cridland
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Simon Pieters
- Re: [hybi] Web Socket IP Authentication Hector Santos
- Re: [hybi] Versioning is a anti-pattern Patrick McManus
- Re: [hybi] Versioning is a anti-pattern John Tamplin
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Willy Tarreau
- Re: [hybi] Versioning is a anti-pattern Scott Ferguson
- Re: [hybi] Versioning is a anti-pattern John Tamplin
- Re: [hybi] Versioning is a anti-pattern Scott Ferguson
- Re: [hybi] Versioning is a anti-pattern John Tamplin
- Re: [hybi] Versioning is a anti-pattern Adam Barth
- Re: [hybi] Versioning is a anti-pattern Martin J. Dürst
- Re: [hybi] Versioning is a anti-pattern David Orchard
- Re: [hybi] Versioning is a anti-pattern Willy Tarreau
- Re: [hybi] Versioning is a anti-pattern Julian Reschke
- Re: [hybi] Versioning is a anti-pattern Adam Barth
- Re: [hybi] Versioning is a anti-pattern Greg Wilkins
- Re: [hybi] List of (mostly) editorial changes for… Greg Wilkins
- Re: [hybi] List of (mostly) editorial changes for… Patrick McManus
- Re: [hybi] List of (mostly) editorial changes for… Greg Wilkins
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Simon Pieters
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Ian Fette (イアンフェッティ)
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Brian McKelvey
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Brian
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Simon Pieters
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… John Tamplin
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Ian Fette (イアンフェッティ)
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Anne van Kesteren
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Ian Fette (イアンフェッティ)
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… John Tamplin
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… S Moonesamy
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Greg Wilkins
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Willy Tarreau
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Ian Fette (イアンフェッティ)
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Anne van Kesteren
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Ian Fette (イアンフェッティ)
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Simon Pieters
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Simon Pieters
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Ian Fette (イアンフェッティ)
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… S Moonesamy
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… Simon Pieters
- Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocke… S Moonesamy
- Re: [hybi] Versioning is a anti-pattern Julian Reschke