2009/7/15 Amos Jeffries <[email protected]>: > a) Getting a dedicated WebSocket port assigned. > * You and the client needing it have an argument to get that port opened > through the firewall. > * Squid and other proxies can be altered to allow CONNECT through to safe > defined ports (80 is not one). Or to do the WebSocket upgrade itself. > > b) accepting that the network being traversed is screwed beyond redemption > by its own policy or admin.
I think the fundamental mistake being made here by Ian (and potentially others) is breaking the assumption that specific protocols exist on the well-known ports. Suddenly treating stuff on port 80 as "almost but not quite HTTP" is bound to cause issues, both devices speaking valid HTTP (eg Squid) and firewalls etc which may treat the exchange as "not HTTP" and decide to start dropping things. Or worse - passing it through, "sort of". Ian - I understand your motivations here but I think it shows a fundamental mis-understanding of the glue which keeps the internet mostly functioning together. Here's a question for you - would you run a mythical protocol, call it "foonet", over IP, if it looked almost-but-not-quite like IP so people could run it on their existing IP networks? Can you see any particular issues with that? Other slots in the mythical OSI stack shouldn't be treated any differently. Adrian
