[whatwg] Web Sockets

[Shannon]

In order to understand this issue better I did some preliminary research 
into how HTTP and common implementations currently support the five 
primary requirements of the WebSocket/TCPSocket proposal; namely 
persistence, asynchronism, security, shared hosting and simplicity. 
After reading http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html I'm 
starting to suspect that both systems can be fully implemented without a 
new connection protocol.

Firstly, according to rfc2616 "In HTTP/1.1, persistent connections are 
the default behavior of any connection."

The other thing about persistent HTTP/1.1 connections is that they are 
already asynchronous. Thanks to pipelining the client may request 
additional data even while receiving it. This makes the whole websockets 
protocol achievable on current HTML4 browsers using a simple application 
or perl wrapper in front of the service ie:

service <--> wrapper <--> webserver (optional) <--> proxy (optional) 
<--> client

a simple pseudo-code wrapper would look like this:

wait for connection;
receive persistent connection request;
pass request body to service;
response = read from service;
response_length = length of response;
send Content-Length: $response_length;
send $response
close request or continue

A threaded wrapper could queue multiple requests and responses.

In theory (as I have yet to perform tests) this solution solves all 
websocket goals:

Simple: Can use CGI (taking advantage of webserver virtual-hosting, 
security, etc...) or basic script wrapper
Persistent: HTTP/1.1 connections are persistent by default
Asynchronous: Requests and responses can be pipelined, meaning requests 
and responses can be transmitted simultaneously and are queued.
Backwards-compatible: Should work with all common HTTP/1.1 compatible 
clients, proxies and servers.
Secure: To exploit a service you would require CGI or dedicated 
application. ISPs tightly control access to these. SSLis easy to 
implement as a tunnel (ie. stunnel) or part of  existing webserver.
Port sharing: This system can co-exist with existing 
webserver/applications on same server using CGI, transparent proxy or 
redirection.

Obviously some real-world testing would be helpful (when I find the 
time) but this raises the question of whether websockets is actually 
necessary at all. Probably the only part HTML5 has to play in this would 
be to ensure that Javascript can open, read, write and close a 
connection object and handle errors in a consistent manner. The 
handshaking requirement and new headers appear to complicate matters 
rather than help.


Shannon