Version 16 of the draft WebSocket protocol specification was just released and the HyBi mailing list announcement for this version contained the following:
Chairs and editors believe that this version is final (before the publication of the RFC). Thank you to everybody who helped to get this completed and for the stimulating discussions on the way.
Now feel free to discuss extensions, WebSocket 1.1, etc. :-).
There are no major differences between this and version 13 and the version number of the protocol itself stays at 13 so The WebSockets Option Pack supports everything that will be in the final RFC.
I’ve just released The WebSockets Option Pack for The Server Framework and I think it’s worth running through why the API that I designed ended up as it did. This will probably end up as part of The Server Framework’s WebSockets documentation, which is currently a little sparse.
The WebSockets protocol is a message based protocol with unbounded message sizes. This makes a general purpose API more difficult to design as some clients of the API may wish to work in terms of discrete messages and some may wish to work in terms of streams of data.
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.
I’m nearing the end of my WebSockets implementation for The Server Framework and have been dealing with various protocol compliance issues. Whilst I have decent unit test coverage I haven’t, yet, sat down and produced compliance specific unit tests which walk through the various parts of the (ever changing) draft RFC and test each aspect. Looking back, I probably should have taken this approach even though the RFC was fluid. Anyway.
As I mentioned here, the WebSockets protocol is, at this point, a bit of a mess due to the evolution of the protocol and the fact that it’s being pulled in various directions by various interested parties. I’m just ranting about some of the things that I find annoying…
The WebSockets protocol includes a way for the endpoints to shut down the connection.
If an endpoint receives a Close frame and that endpoint did not previously send a Close frame, the endpoint MUST send a Close frame in response.
As I mentioned here, the WebSockets protocol is, at this point, a bit of a mess due to the evolution of the protocol and the fact that it’s being pulled in various directions by various interested parties. I’m just ranting about some of the things that I find annoying…
The WebSockets protocol is designed to be extended, which is all well and good. Extensions can, at present, be formally specified by RFCs or be “private use” extensions with names that are prefixed with an “x-”.
I’m currently building a new example server for The Server Framework. This is a variation on one of our proxy server examples for a client that’s doing some WebSockets work. The idea is that the server takes an inbound WebSockets connection, creates an outbound TCP connection to the target server and routes data to and from the remote server and the WebSockets client. It’s fairly simple stuff to put together once you’re up to speed on The Server Framework but my client needed a helping hand and it’s another nice example of what you can do with the framework.
As I mentioned here, the WebSockets protocol is, at this point, a bit of a mess due to the evolution of the protocol and the fact that it’s being pulled in various directions by various interested parties. I’m just ranting about some of the things that I find annoying…
The client MUST mask all frames sent to the server. A server MUST close the connection upon receiving a frame with the MASK bit set to 0.
As I mentioned here, the WebSockets protocol is, at this point, a bit of a mess due to the evolution of the protocol and the fact that it’s being pulled in various directions by various interested parties. I’m just ranting about some of the things that I find annoying…
Back when binary frames were mentioned in the WebSocket protocol specification as a slightly hand wavy “something for the future” and only text frames were actually possible to send and receive using the clients at the time then there MAY (in the strictest RFC meaning of the word) have been a need to differentiate between text and binary frames.
As I mentioned here, the WebSockets protocol is, at this point, a bit of a mess due to the evolution of the protocol and the fact that it’s being pulled in various directions by various interested parties. I’m just ranting about some of the things that I find annoying…
The first thing to realise about the WebSockets protocol is that it isn’t really message based at all despite what the RFC claims.
