[hybi] Websocket: two protocols into one, and Internet rules broken

[Iñaki Baz Castillo <[e-mail]>]

Hi, WebSocket is, most probably, the first protocol in the History of
Internet which is, in fact, two protocols over the same stream
(swtiching from HTTP to WebSocket "pure" binary protocol). As an
author of HTTP commented in this maillist, that is not the aim of HTTP
101 response.

So first, WebSocket uses HTTP for the handshake. This is an extension
to HTTP, of course, and as an extension to HTTP it MUST define HTTP
response codes for certain cases not covered by HTTP itself, but just
by this specification (just talking about HTTP for now). The draft
seems not to want to define such codes:

----------------
   The |Sec-WebSocket-Origin| header is used to protect against
   unauthorized cross-origin use of a WebSocket server by scripts using
   the |WebSocket| API in a Web browser.  The server is informed of the
   script origin generating the WebSocket connection request.  If the
   server does not wish to accept connections from this origin, it can
   choose to reject the connection by sending an appropriate HTTP error
   code.
----------------

Which "appropriate HTTP error code"? Please, define it.

What about if the HTTP handshake request contains an invalid
Sec-WebSocket-Key header? what about if the HTTP request misses some
required header? which HTTP status code should be returned by the
server? Please define it.


In the other side, as I said above WebSocket is the first protocol
that uses two different application protocols (HTTP and WebSocket
binary protocol) within the same transport stream (a TCP connection).
Please don't confuse it with SOAP over HTTP, JSONRPC over HTTP,
anything over HTTP or Flash protocol (RTMP) which is a *single*
protocol over TCP and such protocol contains different payloads for
different application streams (signalling, audio, video...).

The reason this WG gives is that "we want WebSocket to work in any
environment in which HTTP just works". So it assumes that Internet is
broken and HTTP is the only working protocol (or just the only valid
protocol). So, the only way to make a webbrowser to speak a protocol
different than HTTP is by opening first a TCP connection, send a HTTP
request and then "switch" to other protocol. Ugly assumption IMHO.

Have you taken a look to rtc-web? http://rtc-web.alvestrand.com/

  ---------------------
  The RTC-Web effort (Real Time Collaboration on the World Wide Web)
is an effort
  to achieve a standardized infrastructure in Web browsers on which real-time
  interactive communication between users of the World Wide Web can be achieved.
  -----------------------

RTC-Web's aim is to provide realtime communication capabilities to web
browsers, so they could speak other protocols as RTP for audio/video
sessions. Of course I mean pure RTP and not "RTP over HTTP" neither
"first HTTP and then RTP" (following WebSocket fashion).

Now let's imagine we want web browsers to become real SIP or XMPP
clients (I don't mean SIP or XMPP over WebSocket). Do you expect that
the browser will first open a TCP connection, then send an HTTP
"handshake" and then switch same TCP stream to speak SIP or XMPP? and
all this stuff just because "HTTP is the only protocol in the world"?


So, from my point of view, WebSocket breaks Internet model and their
authors should ask themself "who are us to make such aberration in the
History of Internet protocols"?

Please, don't take me wrong. I also assume that there is no way to
rebuild WebSocket with a better design as it would require designing
it from the scratch. So at least, please complete the HTTP part of the
protocol by defining specific HTTP response codes for certain
situations that WebSocket creates (as it is also an extension to HTTP
protocol).

For example, in SIP protocol there are even more SIP response codes
than in HTTP. If a new extension for SIP appears, it may need to
create new response codes or, at least, specify which exact SIP
response codes the server should reply in certain cases (specific to
the given extension). IMHO WebSocket should do the same instead of
trying to avoid responsabilities at HTTP level (since it *does* speak
HTTP).


Regards.


-- 
Iñaki Baz Castillo
<[e-mail]>