If you want to tunnel over proxies, what Websockets (and any of the
other hybi proposals) needs to specify is:
- when (and only when) there is an explicitly configured proxy, use
CONNECT *to* the configured proxy
- otherwise, use a port other than 80 to avoid intercepting
proxies, and do NOT use CONNECT
Regarding ports, your choice will be to use 443 and pretend to be SSL,
or to register a new port for websockets with IANA (as already
suggested).
Note that if you don't actually use SSL on port 443, there's no
guarantee that a stateful firewall (e.g., CheckPoint, although I
haven't used their products in a while) won't inspect the stream and
decide it's bogus.
OTOH if you use a non-443 port, as you've seen it may be blocked.
AFAIK this is quite common, both in existing Squid installs (of which
there are many that squid-dev can't change) and other products.
As mentioned, the best thing is probably to register a new port; that
way, vendors and administrators will know what it is and can account
for it in their products/deployments. It's a lot easier to justify
opening up a port if it's for a well-defined, identified protocol.
BTW, Websockets isn't an "IETF protocol" -- it's a draft that's under
discussion along with a number of other proposals. It may (and
probably will) change, and may never be published as an RFC.
Implementing it now exposes you to the risk of these changes. But you
already know that :)
Cheers,
On 08/07/2009, at 9:01 AM, Alex Rousskov wrote:
The reason I ask is because we're looking to take a patch that
implements the IETF "websockets" protocol:
http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-17
I noticed that in section 3.1.3 the spec relies implicitly on CONNECT
being allowed to arbitrary ports. But this is not the case for
default
installs of squid, and thus I fear that the general approach may be
flawed.
--
Mark Nottingham m...@yahoo-inc.com
