
Let’s take a closer look at the situation. This can’t possibly stand - surely it is a regression in the very core of the web! With much dismay, it appears we’ve lost our WebSockets. Side note: There was a draft proposal to support WebSockets over HTTP/2 but received very little love from the IETF, and, to my knowledge, the endeavour has not been pursued. The two are currently mutually exclusive. However, HTTP/2 expects to continue to exert control and multiplexing over its very precious TCP connection. More generally, a WebSocket expects to be able to make complete use of the TCP connection after stealing it from HTTP. Most Go WebSocket libraries depend on the http.Hijacker interface, and Go doesn’t support this connection. However, our protagonist is notably absent: the WebSocket.Īt the time of writing, all our favourite WebSocket libraries break when facing an HTTP/2 connection. In Go, this is quite straightforward since HTTP/2 has been supported transparently (and by default) since the 1.6 release.

It is 2018, adoption is ubiquitous in browsers, and are working to shift our applications to support and optimize for HTTP/2 everywhere. We finally snapped, and sat down to draft HTTP/2.Ī shining beacon in the dark world of networks, HTTP/2 promised to finally fix several of the problems that had beaten us into submission for years. We were all driven by sprite sheets, domain sharding, and “best practices”, all of which were thinly-veiled illusions for the deep madness that was the battle against networks. WebSockets covered a use case for pages that were already loaded, but moving your average content over the web was still a royal pain.
#NEWSTREAM ENTERPRISE CAREER FULL#
WebSockets made receiving streaming updates from the server a breeze, and since the connection was always there idling for you, repeated requests didn’t have any of the setup overhead as a full HTTP request.įast-forward to four years later - even with all the improvements the new tool had brought we could no longer stand it. A bi-directional pipe between client and server, properly standardized and widely supported, WebSockets became extremely widely used, and grew up alongside the webapp explosion of today’s world. The protocol proceeded to ignore the rest of the standard, setting its own rules for the rest of the session. Neatly sidestepping the issue of HTTP being a half-duplex, WebSockets hijacked an established HTTP connection. No one was willing to go after the root cause of our misery, yet something had to be done - an extension was needed.Įnter everyone’s favourite RFC 6455: The WebSocket Protocol.


It limits speed, brings with it unneeded data overhead, and limits the kinds of patterns you can even consider in designing your applications. This is not terrible if the resource you’re loading is web pages, but if you’re waiting for the server to finish a long running action, keep you informed about a stream of updates, or need to send repeated fast requests then this one-shot request pattern becomes extremely frustrating. The server returns the response, and then immediately forgets the encounter ever occurred. For every piece of data that needs to be transmitted, the clients have to initiate a connection to the server, introduce themselves, authenticate if needed, and request the resource. HTTP/1.1 is fundamentally a stateless request-response protocol. HTTP/1.1 had been the reliable workhorse everyone loved, but some of it’s limitations were starting to become apparent. It was four years before HTTP/2 would reach standard, and the world began to demand increasingly more of communications between web applications and backend services. The year was 2011, well into the life of HTTP/1.1. Today’s battle story covers the adventures of Websockets (and friends). I write about my battles as a cathartic outlet - an intent with a two-pronged purpose: I can share my experiences so others can avoid running headfirst into brick walls, and I refrain from hitting my own against one. The greatest challenge I face daily is that technology advances faster than any standards track could possibly hope to keep up with. I love the work, despite the many frustrations that can come along with it.

My interest in all things technical security has fuelled my career for years.
