Re: [hybi] Working over existing firewalls and proxies

[Mario Balibrera <[e-mail]>]

   - Can you make it tunnel over HTTP when needed?
   - How easily?
   - What are the problems and other issues when doing that?

Currently, js.io works that way with WebSocket. If there is a native browser
implementation available (none yet, obviousy), it uses that to connect
directly to the targeted WS server. Otherwise, it speaks WebSocket protocol
on top of a TCPConnection object (from Orbited, APE, or any other project
imported into the global scope that implements the API), which connects to
its own TCP proxy that in turn connects to the WebSocket server. Easy Peasy.

It would be trivial to add a graceful fallback mechanism, so that it tries
the native WebSocket (as soon as we get one...) and in case of timeout or
immediate connection closure, falls back to HTTP tunneling.

Mario Balibrera

On Tue, Apr 14, 2009 at 8:32 AM, Jamie Lokier <[e-mail]> wrote:

> Greg Wilkins wrote:
> > For example, XMPP has great market share - except when it comes to
> > webchat - where there are now a plethora of alternative protocols
> > for chat - all trying to work out there own way to tunnel through
> > firewalls/gateways and get into the browser DOM.
> >
> > But fundamentally the issue we face is not *what* protocol to use,
> > but how to get it through the internet and into the browser DOM.
>
> I foresee WebSocket in its current form will hit the same problem.
> How to get past firewalls and transparent HTTP proxies.
>
> So will any other proposal, including rHTTP and mine for
> bidirectional/async HTTP.
>
> "The problem of firewalls and transparent proxies in the existing
> infrastructure" is an important topic to address and I think it
> deserves analysis _independent_ of API and low-level protocol.
>
> Here are a few things to consider:
>
>    Corporate firewalls sometimes block all TCP connections,
>    except for port 80 and 443.
>
>    Some firewalls sniff HTTP URLs, HTTP headers and even the content
>    (e.g. checking for viruses), and block based on those.
>
>    Transparent HTTP proxies and proxy-caches on port 80 are common
>    both in corporate settings and home internet connections.  Maybe
>    not the majority of connections (I have no figures), but enough to
>    matter.
>
>    Explicit HTTP proxies which pass HTTP CONNECT requests often
>    limit that to port 443.
>
>    I would be surprised if any widely deployed HTTP proxies, explicit
>    or transparent, currently work with HTTP UPGRADE.
>
>    The Bayeaux people seem to have decided that long-GET is more
>    reliable than slow-streaming-GET, because some HTTP proxies don't
>    forward any of the response until they have received the whole
>    response.  (Is that right?)
>
>    Any apparently-binary protocol which is opaque to intermediate
>    firewalls/proxies is likely to be blocked at many sites who are
>    currently able to use protocols which tunnel over HTTP.  I suspect
>    blanket blocking is more likely when there's no distinguishing
>    metadata in the protocol for a firewall to match on.
>
> > But I think there will only be 1 opportunity this decade to make
> > significant changes to the firewalls/gateways of the internet.
> > If that is true, then is websocket the best change to make?
>
> I think there is 0 opportunity to change the whole internet quickly.
>
> We need to at least _talk about_ whether we care about a new protocol
> interoperating with the existing firewalls/gateways, and if we want to
> provide an upgrade path to help those work with new protocols better.
>
> Issues for specific protocols to consider which might be of concern:
>
>    - Can you make it tunnel over HTTP when needed?
>    - How easily?
>    - What are the problems and other issues when doing that?
>
> It's always possible to tunnel over HTTP, because you can tunnel TCP
> over HTTP, even without CONNECT or UPGRADE), but for some protocols
> it's a poor fit (TCP!), and some fit tunnelling relatively well.  Some
> are even reasonable candidates for firewalls to filter selectively and
> proxies to intercept and cache.
>
> -- Jamie
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>