- From: Shannon <shannon@arc.net.au>
- Date: Tue, 22 Jul 2008 14:47:14 +1000
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
Received on Monday, 21 July 2008 21:47:14 UTC