That is still incorrect. Once the handshake completes the browser absolutely doesn’t care about HTTP with regard to message processing over WebSockets. Therefore just achieve the handshake by any means and WebSockets will work correctly in the browser. The only browser specific behavior of any importance is that RFC6455 masking will occur on all messaging leaving the browser and will fail on all messaging entering the browser.
> You can't just say
I can say that, because I have my own working code that proves it cross browser and I have written perf tools to analyze it with numbers. One of my biggest learnings about software is to always conduct your own performance measurements because developers tend to be universally wrong about performance assumptions and when they are wrong they are frequently wrong by multiple orders of magnitude.
As far as custom implementation goes you gain many liberties after leaving the restrictions of the browser as there are some features you don’t need to execute the protocol and there are features of the protocol the browser does not use.
> That is still incorrect. Once the handshake completes the browser absolutely doesn’t care about HTTP with regard to message processing over WebSockets.
I never made any claim to the contrary.
> Therefore just achieve the handshake by any means and WebSockets will work correctly in the browser.
At which point you're parsing a decent chunk of HTTP.
> I can say that, because I have my own working code that proves it
Writing code doesn't prove anything; code can have bugs. According to the standard portion I quoted, your code is wrong. A conforming request isn't required to match.
> I have written perf tools to analyze it with numbers. One of my biggest learnings about software is to always conduct your own performance measurements because developers tend to be universally wrong about performance assumptions and when they are wrong they are frequently wrong by multiple orders of magnitude.
Performance has absolutely nothing to do with this.
Even if such an implementation appears to work today in browsers, this makes situations with a still-conforming UA damn near impossible to debug, and there's no guarantees made on header ordering, casing, etc. that would mean it would continue to work. Worse, non-conformant implementations like this are the sort of thing that result in ossification.
In my own implementation I wrote a queue system to force message ordering and support offline messaging state and so forth. Control frames can be sent at any time irrespective of message ordering without problems, however.
In the end an in house implementation that allows custom extensions is worth far more than any irrational unfounded fears. If in the future it doesn’t work then just fix the current approach to account for those future issues. In the meantime I can do things nobody else can because I have something nobody else is willing to write.
What’s interesting is that this entire thread is about performance concerns. If you raise a solution that people find unfamiliar all the fear and hostility comes out. To me such contrary behavior suggests performance, in general, isn’t a valid concern to most developers in comparison to comfort.
> You can't just say
I can say that, because I have my own working code that proves it cross browser and I have written perf tools to analyze it with numbers. One of my biggest learnings about software is to always conduct your own performance measurements because developers tend to be universally wrong about performance assumptions and when they are wrong they are frequently wrong by multiple orders of magnitude.
As far as custom implementation goes you gain many liberties after leaving the restrictions of the browser as there are some features you don’t need to execute the protocol and there are features of the protocol the browser does not use.