Subject: [hybi] Comments about draft 10

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 15 Aug 2011 14:30:46 +0200

* Page 6:

   The "Request-URI" of the GET method [RFC2616] is used to identify the
   endpoint of the WebSocket connection, both to allow multiple domains
   to be served from one IP address and to allow multiple WebSocket
   endpoints to be served by a single server.

1) "The "Request-URI" of the GET method" is wrong. The RURI does not
belong to the method but to the request itself so better:

  The "Request-URI" of the GET request

2) What does "both to allow multiple domains" mean there? It's just
speaking about "Request-URI". I propose to re-phrase it as follows:

   The "Request-URI" and Host header of the GET request [RFC2616] are used
   to identify the endpoint of the WebSocket connection, both to allow multiple
   domains to be served from one IP address and to allow multiple WebSocket
   endpoints to be served by a single server.

and remove the next paragraph (which says nothing new):

   The client includes the hostname in the Host header of its handshake
   as per [RFC2616], so that both the client and the server can verify
   that they agree on which host is in use.

* Page 8:

   These fields are checked by the Web browser when it is acting as a
   |WebSocket| client for scripted pages.

1) AFAIK this is not just about Web browsers, but about any WebSocket
client, right? Please, replace "Web browser" with "WebSocket client".

2) The notation of |WebSocket| (using "|" between the world) looks
ugly (at least for me). I've not seen it in other drafts/RFC's. I
would remove all those "|".

* Page 8:

Still is not clear at all how a client should react in case the 101
response has no Sec-WebSocket-Protocol header or it contains a
protocol not present in the request. Example:

- WS client sends GET request with "Sec-WebSocket-Protocol: chat"
- Server replies 101 with:

1) Sec-WebSocket-Protocol: foo
2) Sec-WebSocket-Protocol: foo, chat
3) Sec-WebSocket-Protocol:     (empty header value)
4) No header

How should *exactly* react the WS client in all these cases? The draft
says nothing (AFAIK).

* Page 10:

   Conceptually, WebSocket is really just a layer on top of TCP that
   does the following:

   o  adds a Web "origin"-based security model for browsers

   o  adds an addressing and protocol naming mechanism to support
      multiple services on one port and multiple host names on one IP
      address;

This is not true. Such feature is provided by HTTP protocol
(Request-URI means the server resource to contact and Host header
allows identifying the domain being contacted). I suggest refactoring
this point as (also remove the last ";"):

  -------------------
   o  adds a protocol naming mechanism to support multiple services
      to be provided by the same WebSocket server
  ------------------

   o  layers a framing mechanism on top of TCP to get back to the IP
      packet mechanism that TCP is built on, but without length limits

This is ugly. WebSocket is a layer 5 protocol (application). Could you
please forget layers 3 and 4 for a while please?

   o  includes an additional closing handshake in-band that is designed
      to work in the presence of proxies and other intermediaries

Any application layer protocol should include a "closing" mechanism,
totally independant of TCP connection termination. Protocols, anyway,
can *react* when the TCP connection is closed prematurely, and decide
(or NOT) to terminate the application session. But this is NOT true
for any protocol working on top of TCP (for example in SIP over TCP, a
dialog/call could use different TCP connections for each request, like
the initial INVITE or the BYE after 5 minutes).

Again, don't assume paralelism between layer 4 (TCP) and layer 5. If
WebSocket protocol requires that the TCP connection to be open (which
is legitimate) then mandate that a WS session must be terminated using
WS control messages, and explain that in case of TCP premature
termination, both endpoints should inmediately terminate the WS
session internally.

More later.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: David Endicott <[email-masked]>
Date: Mon, 15 Aug 2011 10:18:50 -0400

On Mon, Aug 15, 2011 at 8:30 AM, Iñaki Baz Castillo <[email-masked]> wrote:

>  The "Request-URI" of the GET request

Some consider the HTTP verbs to represent a "method" on a resource.
"Method" is also in common usage.

> please forget layers 3 and 4 for a while please?

I always (had hoped) that Websocket would be considered a Transport protocol
(ie. the same conceptual layer as TCP) not an application protocol.    Since
Websocket does not define contents (ie. it's content agnostic), it is a
transport protocol.   HTTP is an application protocol because it defines the
type and structure of content and methods of interaction (GET, PUT, etc.)

> termination, both endpoints should inmediately terminate the WS

I continue to push to consider WS to be a Transport protocol.   Like how TCP
and IP are both transports, but TCP is "value-add" and supports streaming
and reliability, WS is a transport that adds functionality to TCP.

If you're going to insist on calling WS an application layer protocol, I
will then insist we define content-type mechanisms.   (But let's not -
that's a bad idea)

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 15 Aug 2011 16:48:03 +0200

More comments:

* Page 29:

   2.   The Method of the request MUST be GET and the HTTP version MUST
        be at least 1.1.

        For example, if the WebSocket URI is "ws://example.com/chat",
        The first line sent should be "GET /chat HTTP/1.1"

No, it could also be an absolute URI:  "GET ws://example.com/chat HTTP/1.1"
In fact next point 3 says that:

   3.   The request MUST contain a "Request-URI" as part of the GET
        method.  This MUST match the /resource name/ Section 3 (a
        relative URI), or be an absolute URI that, when parsed, has a
        matching /resource name/ as well as matching /host/, /port/, and
        appropriate scheme (ws or wss).

   4.   The request MUST contain a "Host" header whose value is equal to
        /host/.

AFAIK "Host" header is not mandatory at all:

a) The server could handle a single domain so ignores the "Host" value.
b) The Request-URI could be an absolute URI so the domain is already
present there.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 21 Aug 2011 17:38:48 +0200

Hi, in my previous two mails in this thread I've reported several
issues/bugs in the draft (revision 10). Some of them could be valid
and others invalid but, could the authors please provide more feedback
when issues are reported?

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>