WebSocket Protocol Updated
Wednesday, June 02, 2010
Labels: websockets
WebSocket is "TCP for the Web," a next-generation full-duplex communication technology for web applications being standardized as a part of Web Applications 1.0. The WebSocket protocol is more efficient than HTTP as used in Ajax, so it is more suitable for real time and dynamic web applications. WebSocket also provides a very simple API that can be used to communicate bidirectionally between the web browser and a server, so it makes it easy to develop such web apps.
We initially implemented WebSocket in WebKit, which has been available in WebKit nightly builds and in Google Chrome. The initial implementation was based on draft-hixie-thewebsocketprotocol-75. Early adopters were able to start developing web apps using WebSocket on real browsers, and provide feedback about the WebSocket specification.
Based on community feedback, the WebSocket specification has been updated to draft-ietf-hybi-thewebsocketprotocol-00 (also known as draft-hixie-thewebsocketprotocol-76).
This version relaxes requirements on handshake messages to make it easier to implement with HTTP libraries, and introduces nonce-based challenge-response to protect from cross protocol attacks. These changes make it incompatible with draft-hixie-thewebsocketprotocol-75; a client implementation of -75 can’t talk with a server implementation of -76, and vice versa.
Developers should be aware that starting from WebKit nightly build r59903 and Chrome 6.0.414.0 (r47952), the client will talk to a server using -76 version of the protocol, so it will fail to open WebSocket connections with a WebSocket server based on draft-hixie-thewebsocketprotocol-75. Since -75 version of the protocol is obsoleted and no longer supported in future version of browsers, to support new clients you need to update the server implementation. (Note that Chrome 5 uses -75 version of protocol).
The WebSocket protocol is still actively being changed. Until there is more consensus, we will continue to update our implementation to follow the latest draft of specification, rather than worrying about breaking changes.
We’re more than happy to hear your feedback, and encourage you to file any bugs you find on our issue tracker.
10 comments:
Chrelad said...
Never developed anything with websockets, but thanks for keeping the development community up to date with changes you are making!
June 2, 2010 8:06 PM
Fredrik said...
WebSocket is not TCP for the web. TCP is binary safe. If updates are being made to the WebSocket protocol, the first one should be to make it binary safe. Have a base 128 varint before the messages telling their length instead of a 0xFF byte after them.
June 3, 2010 1:51 AM
Thomas Broyer said...
Frederik, length-delimited frames are there for a while. Quoting the latest draft:
"Frames denoted by bytes that have the high bit set (0x80 to 0xFF) have a leading length indicator, which is encoded as a series of 7-bit bytes stored in octets with the 8th bit being set for all but the last byte. The remainder of the frame is then as much data as was specified."
June 3, 2010 2:13 AM
Fredrik said...
Thomas, that's good, but it's only used for types of frames that can only be used in the “future”: “The protocol is designed to support other frame types in future. Instead of the 0x00 and 0xFF bytes, other bytes might in future be defined.”
It should apply for all frame types. (0x00 to 0x7F also.) It makes no sense two have two special cases.
June 3, 2010 6:22 AM
Thomas Broyer said...
It's for the "future" because the only WebSocket clients for now are browsers, and they do not support binary data yet.
As for the "all frames should be length-delimited" thing, it would preclude incremental serialization of objects: you'd have to compute their serialized size first, whereas with the 0xFF marker byte you just have to serialize directly to the stream and append a 0xFF when you're done. It can come in handy when sending an XML or HTML document or fragment: the browser can optimize things by serializing directly to the stream (the WebSocket API requires a DOMString, but the JavaScript binding says that values should be coerced into a String, and this is the thing that be optimized by browsers with marker-delimited frames when you pass a host object as argument)
June 3, 2010 6:45 AM
Mibbit said...
Sorry but the spec for this is just ridiculous. It's insane. It contains the code to parse HTTP headers, translated into *english*. You could easily condense this spec down to a couple of pages, and it'd actually be usable.
Once again, sorry, but this is just ridiculous.
June 3, 2010 10:31 AM
cgbystrom said...
It's not easy balancing on the bleeding edge.
Right now I've already made http://beaconpush.com support two different versions of Web Sockets implemented by different versions of Google Chrome.
(There were differences in the handshake origin URL).
Don't get me wrong though, I'm not complaining. I knew what could happen. It's just that the hype surrounding Web Sockets rarely mention these more cumbersome details of the protocol still being a draft.
June 3, 2010 2:21 PM
Greg Wilkins said...
The Jetty-7 server now supports both the hixie-75 and ietf-00 forms of the protocol. It uses the presence of Sec-Websocket headers to choose which form of the protocol to support.
This is in the trunk now and pushed snapshots. It will soon be supported in the 7.1.4 release.
June 3, 2010 8:28 PM
Crotch-Eye-View said...
get apache httpd and microsoft and all the firewall manufacturers and all the network intrusion detectors to ALLOW you to tweak http and go full duplex, and THEN I will code line 1 that uses the WebSockets API.
Goog has the muscle, vision, and payola to make this happen, I don't doubt that ... but you all have a LONG row to hoe before you get my undivided attention. I'm guessing WebSockets will be applicable widely in, hrmmm, 2017. (How close am I?)
June 19, 2010 10:18 PM
Andre said...
Before developing fancy stuff for Chromium, basic things like backspace or opening external applications should really work.
It's a real shame that backspace does not work. You need therefore an extension (which does not work either).
6.0.444.0 (50329) Ubuntu
June 23, 2010 5:24 AM
Post a Comment