I'm curious if there was ever a time when WebSockets were fully dependent on HTTP for communication, not just during the initial handshake? I've heard from some colleagues that there were security restrictions that kept browsers from exposing TCP socket APIs, which might explain this. I remember reading about this in various resources, but I can't find anything on it now. Am I just imagining this, or was there an actual period when WebSockets operated this way?
4 Answers
Some libraries like Socket.IO do fall back to HTTP long polling if the browser or device doesn't support WebSockets. That might be what's confusing you. It's not that WebSockets themselves relied on HTTP completely, though.
Most WebSocket libraries fall back on HTTP if WebSockets aren't viable, using polling for that. As far as I know, the original WebSockets use HTTP to set things up, and that's been consistent.
Thanks for clarifying! As mentioned earlier, I might have confused actual WebSocket implementations with early Socket.IO versions.
There are quite a few methods to keep an HTTP connection open without necessarily using WebSockets or SSE (Server-Sent Events). Maybe that's what you were recalling?
Yeah, other users pointed out that I was mixing up real WebSocket implementations with some early Socket.IO work. Appreciate your help!
Nope, aside from the handshake, WebSockets operate differently. Developers did try to create socket-like interactions using HTTP in the past, especially with long polling. For more details, check out RFC 6455.
Got it. Do you remember if Socket.IO was around before the full adoption of RFC 6455? I might be mixing up real WebSocket tech with some early implementation I saw.
Ah, those were interesting times! I was writing similar code in the early 2000s—emulating data sending with flushes via iframes.
Thanks for the input! I chatted with someone else about this and found out that Socket.IO existed before RFC 6455, so I might have mixed things up back then.