[hybi] Working over existing firewalls and proxies

[Jamie Lokier <[e-mail]>]

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