Re: [hybi] workability (or otherwise) of HTTP upgrade

[John Tamplin <[e-mail]>]

On Fri, Nov 26, 2010 at 7:55 AM, Greg Wilkins <[e-mail]> wrote:
>
> On 26 November 2010 18:03, Eric J. Bowman <[e-mail]> wrote:
> > What about:  3) Use another port?  I've seen that opinion voiced, so I
> > haven't signed up to the hybi list to voice it myself.  No criticism of
> > Web Sockets is intended or implied here, it's just a concrete example of
> > something which increasingly concerns me regarding Upgrade.
>
> The problem with another port, is that the success rate of  opening an
> arbitrary port through firewalls is not that high.     Thus if
> websocket was allocated it's own sockets, then there would still be
> need for a websocket over 80 protocol (eg like there is BOSH for
> XMPP).

In practice, those with firewalls aren't going to transport WebSocket
work anyway.  Maybe firewall configurations will be updated, but all
the ones I tested on the proposed method of connecting to the proxy
and issuing a CONNECT to the ultimate server fails on anything except
port 443.  So, WebSocket servers on port 80 being accessed from behind
non-transparent proxies (which cover the majority of corporate
environments) isn't going to work anyway.  I think someone deploying a
WebSocket server they expect to be accessible from behind those
proxies will have to run it on port 443.

Aside from running on port 443 (which has its own benefits, as you
could argue at this point we shouldn't be sending user data in the
clear ever), the only way I see getting through those proxies is using
POST with chunked encoding in both directions to send individual
frames but that is likely to run into its own problems and would
likely complicate server implementaitons.  Alternatively, hope that
WebSockets content becomes popular enough to force those environments
to be updated to allow it.

--
John A. Tamplin
Software Engineer (GWT), Google