I was in a mess and this is the blog which gave me clue out of it.
I had created two simple examples of websocket implementation using yet to realease spring 4 support for websockets.
I tested it from home and all well and good (no issues).
Next day I tried to demo it in my team –and the HTTP version failed, but to surprise the HTTPS was still good and saved my day!
I realized that I have not done my homework properly –rather impressed by simplicity of spring, have rushed in implementation. While searching for the issue I stumbled on the above article –it turns out that “Automatic Proxy” at office network was culprit. Here is the story
- We have “automatic proxy ” at work place –meaning no explicit IP or script in proxy tab in browser setting, once on network, transparent proxies are used.
- For HTTP :: Since browser was not aware of any explicit proxy, it addressed the Web socket server and while passing through the transparent proxy, required headers were removed. Websocket is an http upgrade (communicated via certain header, above article have all the details) -since headers were removed, the end server could not make sense of it and treated as simple HTTP
- For HTTPS :: Again browser was not aware of proxy, but since data was encrypted –proxy did not tampered the header and request went through to the actual server -since headers were still there all went good and fine!
- Spring web socket client (Sockjs) was smart enough to switch to WSS when I used HTTPS –which I did not realize at first shot. Lesson learned -test stuff behind proxy, firewalls even if it is an internal demo 🙂
In actual scenario –in any of corporate deployment, it’s going to be a HTTPS, so seems that web socket have a very good story there!