43 ms·

The WebSocket protocol "Last Call"

58 points by frsyuki 15y ago

andypants 15y ago
Finally! I'm sick of web hosts claiming the protocol is still changing constantly, so they won't support websockets on their servers.
- pilif 15y ago
  in their defense though, that was (and is - until the final RFC is released) true. Depending on your infrastructure (reverse proxies, firewalls) supporting just one version can already be painful. Supporting different versions, incompatible to each other is even more painful. And as a generic host you can't make all your customers constantly update their application especially when you consider that various browsers out there support (or don't support) different revisions of the protocol.
braindead_in 15y ago
Is there a good overview of websockets? I just glanced at the spec and it looks quite complex. Especially the part about framing. Do websockets have any relation to TCP sockets? If over TCP, why do they use their own framing?
- udp 15y ago
  Because TCP doesn't provide any framing - it's just a stream of data. Text based protocols usually use newlines as delimiters, and binary protocols usually prefix each message with a size.
metabrew 15y ago
Is there a good 'diff', detailing what's changed between revisions? I need to read up on the latest version - anyone know if it avoids breaking http, and will work with proxies out of the box? (ie no essential body data without a content-length header)
- yuhong 15y ago
  Yep, they use masking to prevent security holes in proxies from being exploited.
- mloughran 15y ago
  Yes, you can get a text diff from http://datatracker.ietf.org/doc/draft-ietf-hybi-thewebsocketprotocol/history/ http://datatracker.ietf.org/doc/draft-ietf-hybi-thewebsocket...
pilif 15y ago
As people here seem to really like and actively use WebSockets already, let me ask a question: How well does this behave with various proxy servers on both ends (client and server)? I have this nagging feeling that yet another cool technology will probably not be usable for the foreseeable future because it gets broken in unpredictable ways by either forced proxy servers or, my bane of existence, personal firewalls. Are there numbers out there about percentages of successful connections (though considering browser support, those numbers are probably skewed because this is still limited to early adopters which either don't run personal firewalls or are able to fix them)? If connections fail, how do they fail?
- metabrew 15y ago
  The version of websockets currently in the wild (-76) doesn't play well with proxies at all. The handshake requires sending 8 bytes of body data, without a suitable content-length header. Without the content-length header, http proxies won't pass on those 8 bytes, so handshakes fail. Hopefully this is addressed in the newest revision.
  - speckledjim 15y ago
    All 3 versions are reasonably successful, and in any event, it's not rocket science to try websocket and fallback on comet upon failure. The latest version is probably the most robust if your ISP likes fiddling with your HTTP though.
    - metabrew 15y ago
      It's not about ISPs fiddling with HTTP, it's about using existing reverse proxies / load balancers, such as nginx, haproxy, perlbal, pound, etc. None of them work in HTTP mode with the spec currently in the wild. If you use a non-layer7 balancer, you lose the ability to inject X-Forwarded-For. It's a real concern for sites that serve websocket traffic from more than one machine.
      - speckledjim 15y ago

58 points by frsyuki 15y ago

Finally! I'm sick of web hosts claiming the protocol is still changing constantly, so they won't support websockets on their servers.

pilif 15y ago
in their defense though, that was (and is - until the final RFC is released) true. Depending on your infrastructure (reverse proxies, firewalls) supporting just one version can already be painful. Supporting different versions, incompatible to each other is even more painful. And as a generic host you can't make all your customers constantly update their application especially when you consider that various browsers out there support (or don't support) different revisions of the protocol.

braindead_in 15y ago

Is there a good overview of websockets? I just glanced at the spec and it looks quite complex. Especially the part about framing. Do websockets have any relation to TCP sockets? If over TCP, why do they use their own framing?

udp 15y ago
Because TCP doesn't provide any framing - it's just a stream of data. Text based protocols usually use newlines as delimiters, and binary protocols usually prefix each message with a size.

metabrew 15y ago

Is there a good 'diff', detailing what's changed between revisions? I need to read up on the latest version - anyone know if it avoids breaking http, and will work with proxies out of the box? (ie no essential body data without a content-length header)

yuhong 15y ago
Yep, they use masking to prevent security holes in proxies from being exploited.
mloughran 15y ago
Yes, you can get a text diff from http://datatracker.ietf.org/doc/draft-ietf-hybi-thewebsocketprotocol/history/ http://datatracker.ietf.org/doc/draft-ietf-hybi-thewebsocket...

pilif 15y ago

As people here seem to really like and actively use WebSockets already, let me ask a question: How well does this behave with various proxy servers on both ends (client and server)? I have this nagging feeling that yet another cool technology will probably not be usable for the foreseeable future because it gets broken in unpredictable ways by either forced proxy servers or, my bane of existence, personal firewalls. Are there numbers out there about percentages of successful connections (though considering browser support, those numbers are probably skewed because this is still limited to early adopters which either don't run personal firewalls or are able to fix them)? If connections fail, how do they fail?

metabrew 15y ago
The version of websockets currently in the wild (-76) doesn't play well with proxies at all. The handshake requires sending 8 bytes of body data, without a suitable content-length header. Without the content-length header, http proxies won't pass on those 8 bytes, so handshakes fail. Hopefully this is addressed in the newest revision.
- speckledjim 15y ago
  All 3 versions are reasonably successful, and in any event, it's not rocket science to try websocket and fallback on comet upon failure. The latest version is probably the most robust if your ISP likes fiddling with your HTTP though.
  - metabrew 15y ago
    It's not about ISPs fiddling with HTTP, it's about using existing reverse proxies / load balancers, such as nginx, haproxy, perlbal, pound, etc. None of them work in HTTP mode with the spec currently in the wild. If you use a non-layer7 balancer, you lose the ability to inject X-Forwarded-For. It's a real concern for sites that serve websocket traffic from more than one machine.
    - speckledjim 15y ago