Re: [hybi] [whatwg] Web sockets and existing HTTP stacks

[Jamie Lokier <[e-mail]>]

Justin Erenkrantz wrote:
> On Fri, Dec 18, 2009 at 4:54 PM, Jamie Lokier <[e-mail]> wrote:
> > Given WebSocket's stated goals (on this list) of:
> >
> >   - Not working through HTTP proxies, including intercepting proxies.
> >   - Not being HTTP compatible.
> >   - Not being correctly parsable by a correct HTTP request parser.
> >
> > I'm thinking it would be easier to just use port 81 and be done with it.
> 
> Proxies (mainly reverse proxies) and caching are incredibly important
> to any real scalability efforts.  I'm not aware of many high-traffic
> web setups that don't rely upon massive amounts of front-ends.  So,
> any port 80 traffic to any big sites is very likely to hit an hardware
> box (F5, etc.) or a software balancer (a la mod_proxy or varnish or
> squid).  If the current WebSockets ID is intended to *fail* in those
> situations, the deployment story is likely to be a real non-starter...

(Note that I prefer BWTP myself; I'm just describing WebSocket).

It fails early because the alternative, for a pure HTTP proxy, is
unpredictable behaviour when it sees bidirectional messages later.
Failing early is a good thing!

It won't fail if the proxy explicitly supports WebSocket, so adding
that support is the intended solution, I believe.

A pure HTTP proxy cannot carry any of the protocols under discussion,
except for those designed to look like normal HTTP unidirectional
request-response pairs ("polling", "long GET" and "streaming GET"),
which are already widely implemented.

If you are looking for an efficient bidirectional messaging protocol
which works with pure HTTP proxies, not modified to support the
bidirectional protocol, what do you suggest?

> I'm curious what the makeup of this hybi@ list/WG is - how many server
> or intermediary devs are on this?  From browsing the archives, it
> looks like it is mostly browser/user-agent developers so far.

I'd say there are many server and application developers on the list
(including me), but the WebSocket protocol appears to be more driven
from the browser API side.  It is explicitly designed to support a
Javascript API, and pays little attention to issues like network
performance and scalability.

-- Jamie