

The WebSocket protocol "Last Call" - frsyuki
http://datatracker.ietf.org/doc/draft-ietf-hybi-thewebsocketprotocol/

======
pilif
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
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
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
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
Firefox 6 uses the latest spec. So it's active in the wild already.

I don't think reverse proxies are that big a deal personally, as you as a
website owner have control of that part of the system. If the reverse proxy
can't deal with it, fix it so it can or use a different one or write your own.

There's certainly ISPs out there that proxy all HTTP through their own
cache/proxies and fallover with previous spec websocket. Of course the
alternative is just to use HTTPS.

------
metabrew
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)

~~~
mloughran
Yes, you can get a text diff from [http://datatracker.ietf.org/doc/draft-ietf-
hybi-thewebsocket...](http://datatracker.ietf.org/doc/draft-ietf-hybi-
thewebsocketprotocol/history/)

------
braindead_in
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
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.

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

~~~
pilif
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.

