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
