3 ms·

Just a remark: You can use the websocket spec to emulate TCP behavior, which means get a stream instead of messages: Send only one giant message (payload set th

Just a remark: You can use the websocket spec to emulate TCP behavior, which means get a stream instead of messages: Send only one giant message (payload set the maximum) and use Continuation frames to stream new chunks of data to the other side. FIN will be only set once the stream has finished. The downside: A lot of websocket APIs (and most especially the one in the browser) don't support this and will only send/receive complete messages. Which means if you want streaming support you better implement it as a layer on top of messages, since it works everywhere. It's a little bit sad that the websocket spec is complicated through the continuation frame feature while in reality noone has a reason to use it. And back to the question: The masking "feature" of websockets is also there to prevent browsers from speaking raw TCP. Without it Javascript could craft exact TCP payloads, which might in certain situations be used to directly talk and manipulate internal services. The masking guarantees that the remote on the TCP connection will get some random data after the websocket header.

kuschku 10y ago
The problem that's missing is being able to speak to existing services without requiring them to implement a websocket interface. The entire websocket code should have never existed in the first place — just use standard TCP with standard TLS, like any other system, too. Maybe require a browser permission for that, and that issue is solved, too.
- Matthias247 10y ago
  I guess they didn't want browsers to annoy users with popups like: "Do you want to allow a TCP connection to host.com:234?" The average user would have no idea what this means and would just accept anything. Maybe they could have elided the check if the destination uses the same host than where the HTML/JS was delivered from, but that would still leave some questions unanswered.
yokohummer7 10y ago
That's interesting, I've always thought the WebSocket spec is too complicated with all those frame types and message fragmentation, and I completely ignored contunation frames when I had to implement the protocol myself. But it seems more versatile than I imagined. Though the workaround you mentioned sounds a bit hacky. And yeah, I now remember that masking was also a problem at the time. So even if web browsers adopt a new API to send fragmented messages, it would still not be possible to directly plug in them to legacy servers. Sad. Edit: It would also be possible to send a single giant message, which contains a single giant continuation frame sent for the lifetime of the session, which is followed by a FIN frame. Am I correct?
- Matthias247 10y ago
  Yes, you could use the single giant message too. The drawback to the continuation frame approach is that you can't interleave it with ping frames (for connectivity checks) and that you won't be able to signal end of stream (FIN). If that's not required because your higher level protocol takes care of that things otherwise it would be fine.

kuschku 10y ago

The problem that's missing is being able to speak to existing services without requiring them to implement a websocket interface. The entire websocket code should have never existed in the first place — just use standard TCP with standard TLS, like any other system, too. Maybe require a browser permission for that, and that issue is solved, too.

Matthias247 10y ago
I guess they didn't want browsers to annoy users with popups like: "Do you want to allow a TCP connection to host.com:234?" The average user would have no idea what this means and would just accept anything. Maybe they could have elided the check if the destination uses the same host than where the HTML/JS was delivered from, but that would still leave some questions unanswered.

yokohummer7 10y ago

That's interesting, I've always thought the WebSocket spec is too complicated with all those frame types and message fragmentation, and I completely ignored contunation frames when I had to implement the protocol myself. But it seems more versatile than I imagined. Though the workaround you mentioned sounds a bit hacky. And yeah, I now remember that masking was also a problem at the time. So even if web browsers adopt a new API to send fragmented messages, it would still not be possible to directly plug in them to legacy servers. Sad. Edit: It would also be possible to send a single giant message, which contains a single giant continuation frame sent for the lifetime of the session, which is followed by a FIN frame. Am I correct?

Matthias247 10y ago
Yes, you could use the single giant message too. The drawback to the continuation frame approach is that you can't interleave it with ping frames (for connectivity checks) and that you won't be able to signal end of stream (FIN). If that's not required because your higher level protocol takes care of that things otherwise it would be fine.