

Web Sockets specification (IETF Internet Draft) - jsrn
http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-54

======
huhtenberg
The C for RFC in short - What's the point ?

I really don't understand what problem this draft solves, and the draft
doesn't seem to explain it coherently.

It effectively describes just another layer on top of TCP that implements its
own addressing, loosely follows HTTP syntax and utilizes TLS for security. The
application still needs to implement yet another layer to deal with the data
carried by this protocol. So instead of using (TLS + application protocol)
combo, the app needs to use (TLS + WS + application protocol).

So what's the point in making this protocol a standard ?

\-- PS --

 _Historically, creating an instant messenger chat client as a Web application
has required an abuse of HTTP to poll the server for updates while sending
upstream notifications as distinct HTTP calls._

Perhaps that's how they do it at Google, but _historically_ applications like
httptunnel simply opened exactly two persistent HTTP connections - one with a
very long POST and the other one with a very long GET - and used them to send
data up and down respectively.

~~~
jacobolus
The point is, roughly, making a protocol for browsers to communicate bi-
directionally with servers (that is, either side can send data to the other at
any time; this spec tries to provide semantics of a TCP socket), which (a)
gets through proxies and firewalls, (b) has as little overhead as possible,
and (c) has no potential security vulnerabilities not already present in other
types of browser connections (XHR, etc.).

Currently, the set of techniques collectively called "Comet" are inconsistent
across browsers, fragile to new browser version changes, and extremely hacky.

> _The application still needs to implement yet another layer to deal with the
> data_

Well sure, the application needs to implement the semantics of whatever the
particular network app is that will communicate with a method like this. But
that's always been true for any application. Something like this just tries to
give web applications some of the same flexibility that applications with more
access to the OS, and which could therefore just open TCP sockets, always had.

