The WebSocket protocol - Draft, HyBi 13
Another day, another WebSocket protocol draft…
That’s probably a little unfair actually. Although there have been several drafts in quick succession over the past few weeks the protocol itself has only changed very slightly. The majority of the changes have simply been to the wording and arrangement of the document.
I was fairly cynical about the likely quality of the final RFC when I started looking at the 09 draft and then, in search of clarification, started following the HyBi Working Group’s mailing list. As I said at the time, there are a lot of interested parties and they all want their own special requirements reflected in the document. What I wasn’t really aware of then was that once the document moved towards standardisation the issues would be managed in a much more controlled manner. Since then, Peter Saint-Andre has guided the Working Group and the document in a subtle but controlled manner. The discussions have still been heated (and in many cases circular) but each outstanding issue has finally been resolved and the document has moved forward.
When I started following the Working Group I felt that I couldn’t make a difference. There were lots of loud personalities that had been involved from the start and came across as having a lot more weight in the process than others on the list. I’m pleased that I decided to ignore my initial fears and raise some of the issues that I was concerned about as in some cases I feel that it made a difference.
So, where are we on my list of rants from back in July?
-
WebSockets is a stream, not a message based protocol… - The wording of the RFC has been changed so that it doesn’t imply that a message based API is the only one that should be considered and private use extension tokens are no longer allowed (so no x-tcp-stream)
-
Why differentiate between text and binary frames? - No change. The WebSocket protocol needs to deal with UTF8 transformations just so that the users don’t.
-
Why do we need to mask data from client to server? - The document has been updated to explain the rationale behind this requirement.
-
How the deflate-stream extension is broken and badly designed - The extension has been removed.
-
I miss the TCP half-close - No change.
So the main issues that I was concerned about have been dealt with and the remaining two are pretty minor. It’s somewhat annoying that deflate-stream
was removed after I implemented it, but since I implemented it as a general purpose connection filter the code can be reused by anyone using The Server Framework who wants to deflate their TCP data.
WebSocket support is available in The Server Framework from release 6.5 which is currently in final testing.