I really like the idea behind the HTML5 Websocket API – namely that a datagram model should be used for web application communication rather than a request/response paradigm (this is also the idea behind cometd). But unfortunately, the proposed protocol to carry websocket traffic is neither a good protocol nor is it well specified.
After failing in an attempt to get the WebSocket protocol improved, I decided to try to define a better solution. I had intended to work privately on this for a while, but the twittersphere has pointed out an early draft, so I’ve put the work-in-progress on http://bwtp.wikidot.com and I invite review, feedback and collaborators.
So what’s so bad about the Websocket protocol proposal? The main things I dislike are that the document is impenetrable, the protocol inflexible and it is entirely different from other IETF application protocols for no good reason. But rather than throw (more)mud, I’d rather sing the praises of the approach that I have taken:
- The BTWP protocol is very much an IETF style application protocol. In fact it is just RFC2616 with anything non bidirectional ripped out. It is not trying to be a revolution in web protocols, but simply to solve the problems at hand, without discarding decades of protocol experience.
- The protocol document is written very much in IETF style. In fact it is just RFC2616 with anything non bidirectional ripped out. BNF is used to specify the protocol and unlike the WebSocket proposal there are no binary blobs or algorithmic specifications.
- The principal of “be strict in what you generate and forgiving in what your parse” is adhered to.
- Because of it’s similarity to HTTP, it is intended that existing HTTP clients, servers and intermediaries will be able to be minimally updated to support this protocol. This will not require entirely new protocol libraries to be developed.
- Existing development and analysis tools will also be able to be easily updated, plus the protocol is mostly human readable.
- It supports full mime encapsulated payloads, so non text payload and/or compressed payloads can be sent without the need for clent and server to make assumptions with regards to content.
- It has a default meta data mechanism, so that it can have detail per message meta data, but not at the expense of the redundent inforamation sent in normal HTTP.
- The minimal overhead per message is 11 bytes, which is a little more than the websocket proposal, but is hardly significant.
- There is no formal channel mechanism like BEEP has, but each message may be to/from a different URI if need be. This makes multiplexing easy to support.
- There is no formal segmentation mechanism, but Content-Ranges are supported so that large content can be sent in smaller bits if desired.
- The protocol recognizes that intermediaries (proxies) may wish to be an active party on a bi direction connection. For example, this proposal allows an intermediary to initiate and orderly lossless close of the connection. I’m sure innovative proxy applications will be developed over time, just as they have been for HTTP.
- BWTP well supports the current HTML WebSocket API but is also flexible and extensible so that non browser clients may use it and future APIs will not need protocol changes.
If you are interested, I encourage you to join the IETF Hybi mailing list and to join the discussion ragarding the bidirectional web.
2 Comments
Patrick Mueller · 12/06/2009 at 13:50
Have you posted comments on the HTML5 WebSocket proposal anywhere? Like the what-wg ml? It would be great to have a discussion on this there. I mainly point this out as there has been very little discussion of WebSocket anywhere. Time to shine some light on the subject.
Personally, I either understand the WebSocket proposal and find it underwhelming, or I don’t understand it.
Juanchy · 03/03/2012 at 21:13
Asa, I don’t know if other vendors will foollw suit. That’s up to them. There’s a hint that Apple might, based on a comment from an Apple developer, but they don’t pre-announce things like this.Regarding the transparent vs. not it doesn’t matter if it’s broken proxies or not. We have to mitigate the risk of operating on the web which is filled with messy and broken stuff. And the fact that it’s a cache proxy issue means that it doesn’t just affect one person, but can affect everyone behind that proxy. That can mean anywhere from dozens to millions of people, depending on the proxy. So it would be inappropriate of us to leave this issue as someone else’s problem to fix. We’re interested in being part of the solution, not assigning blame.Note the flash issue, which still exists. This is also a problem in flash, and I’m not sure if or what Adobe will do about it. (The vulnerability was actually demonstrated in Flash, but also may affect the in-browser websocket implementations. But the risk is high enough where we are disabling it.) Same as the other vendors it’s up to them to decide what they want to do on behalf of their users. And, I guess, what risk they will be willing to expose other users of other browsers to as well, since if affects proxies.
Comments are closed.