[hybi] -09: handshake

[Peter Saint-Andre <[e-mail]>]

Here are some comments on Section 5, again mostly editorial...

Section 5.1 uses the terms "/resource name/" whereas Section 3 uses the
term "resource-name".

Section 5.1 talks about a "/secure/ flag" but that term is not used in
Section 3. Perhaps modify the latter to say:

   The URI is called "secure" (and it said that "the secure flag is
   set") if the scheme component matches "wss" case-insensitively.

Change "may" to "MAY" in this sentence...

   Clients 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.

It's not clear to me what we mean by "another agent". Is this, for
example, separate software that runs on the same handset as the
WebSocket, an application provided by the handset manufacturer or
service provider that the handset client interacts with via an API, some
kind of third-party service, or any of the above?

There are a few confusing phrases and long sentences here:

       If the client cannot determine the IP address of the remote host
       (for example because all communication is being done through a
       proxy server that performs DNS queries itself), then the client
       MUST assume for the purposes of this step that each host name
       refers to a distinct remote host, and should instead limit the
       total number of simultaneous connections that are not established
       to a reasonably low number (e.g., in a Web browser, simultaneous
       pending connections to a.example.com and b.example.com would be
       allowed, but if thirty connections are requested, that may not be
       allowed.  The limit should consider the number of tabs the user
       has open.

I suggest:

       If the client cannot determine the IP address of the remote host
       (for example because all communication is being done through a
       proxy server that performs DNS queries itself), then the client
       MUST assume for the purposes of this step that each host name
       refers to a distinct remote host.  Instead, the client SHOULD
       limit the total number of simultaneous pending connections to a
       reasonably low number (e.g., the client might allow simultaneous
       pending connections to a.example.com and b.example.com, but
       might not allow thirty simultaneous pending connections to
       various hosts).  In a Web browser context, the client SHOULD
       consider the number of tabs the user has open in setting a limit
       to the number of simultaneous pending connections.

I have one nit and one concern with this text:

       NOTE: This makes it harder for a script to perform a denial of
       service attack by just opening a large number of WebSocket
       connections to a remote host.  A server can further reduce the
       load on itself when attacked by making use of this by pausing
       before closing the connection, as that will reduce the rate at
       which the client reconnects.

Nit: change "by making use of this by pausing before closing the
connection" to "by pausing before closing the connection".

Concern: this specification says nothing about the reconnection logic.
You might adapt some of the text from Section 3.3 of RFC 6120:

###

3.3.  Reconnection

   It can happen that an XMPP server goes offline unexpectedly while
   servicing TCP connections from connected clients and remote servers.
   Because the number of such connections can be quite large, the
   reconnection algorithm employed by entities that seek to reconnect
   can have a significant impact on software performance and network
   congestion.  If an entity chooses to reconnect, it:

   o  SHOULD set the number of seconds that expire before reconnecting
      to an unpredictable number between 0 and 60 (this helps to ensure
      that not all entities attempt to reconnect at exactly the same
      number of seconds after being disconnected).

   o  SHOULD back off increasingly on the time between subsequent
      reconnection attempts (e.g., in accordance with "truncated binary
      exponential backoff" as described in [ETHERNET]) if the first
      reconnection attempt does not succeed.

###

A question about this text:

       Servers
       can refuse to accept connections from hosts with an excessive
       number of existing connections

Do we mean "hosts" here or instead "clients" or "IP addresses"?

   3.  _Proxy Usage_: If the client is configured to use a proxy when
       using the WebSocket protocol to connect to host /host/ and/or
       port /port/, then the client SHOULD connect to that proxy and ask
       it to open a TCP connection to the host given by /host/ and the
       port given by /port/.

Do we really mean "and/or"? I don't think you can connect to just a port. :)

s/SOCKS/SOCKS5 [RFC1928]/

s/[RFC3548]/[RFC4648]/

Please also specify which flavor of base64 (Section 4 or Section 5 of
RFC 4648) and specify whether padding bits are included at the end of
the block.

It looks as if [I-D.ietf-websec-origin] is a normative reference, since
we're taking the ABNF for the "Sec-WebSocket-Origin" from that spec. I
don't think that should hold up publication of the WebSocket spec, but
if you're worried about that then please provide reviews of the same
origin spec on the WebSec list. :)

https://www.ietf.org/mailman/listinfo/websec

   10.  The request MAY include a header with the name "Sec-WebSocket-
        Protocol".  If present, this value indicates the subprotocol(s)
        the client wishes to speak, ordered by preference.

Please specify that the subprotocols are provided in a comma-separated
list. (And again in Section 5.2.1.)

   Once the client's opening handshake has been sent, the client MUST
   wait for a response from the server before sending any further data.

I don't see anywhere a definition of the server's behavior (e.g., it
MUST close the WebSocket if the client tries to send data before the
server sends a response).

In Section 5.2.2...

   At this point, the server may begin
   sending (and receiving) data.

I think at this point both parties (client and server) are allowed to
send data, right?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/