A Proxy-savvy Socket in ActionScript 3

I’m working on an Apollo application that needs to make a TCP connection on a "non-standard" port, which, depending on your environment, usually means a port other than 80, 443, and few other commonly used ports. Development was going fine thanks to the new ActionScript 3 socket object until I went into the San Jose office to work for a day and discovered that the San Jose firewall is much stricter than the San Francisco one, and the port I was trying to connect on was blocked.

Fortunately, most environments with strict firewall rules also provide a way to get around them in the form of an HTTP proxy. After a little research and conferring with Chris Brichford, an Apollo engineer, we decided that this is a common enough problem that it would be worth solving in a generic way. So I wrote the RFC2817Socket class.

RFC 2817 "explains how to use the Upgrade mechanism in HTTP/1.1 to initiate Transport Layer Security (TLS) over an existing TCP connection." Not entirely relevant to our problem, however it also "documents the HTTP CONNECT method for establishing end-to-end tunnels across HTTP proxies" which means we can use a common HTTP proxy to make TCP connections on non-standard ports.

The RFC2817Socket class works exactly like the flash.net.Socket class, but if you give it proxy settings by calling setProxyInfo before calling connect, it will first handle the negotiation with the proxy server before dispatching the Event.CONNECT event. (If you don’t set proxy settings, it will work just like the standard socket class.) All you have to know is your proxy server’s hostname and port number, and RFC2817Socket takes care of the rest.

Unfortunately, this may not be the entire story, though. The reason I chose such a clumsy name for the class is that it will only work with proxy servers who adhere to RFC 2817. I suspect that most, if not all, proxies will use this technique (since it is a "standard"), however since I don’t have a bunch of other proxies to test with, I have no way of knowing for certain. If it turns out that other proxies use different techniques for tunneling TCP connections, the thing to do would be to create other implementations in the same package, and then create a factory to return the right one. I’m hoping that the RFC2817Socket will work with most proxies out there so that won’t be necessary, however if you find that it doesn’t, it shouldn’t be difficult to write one that does (if I can access the proxy that it doesn’t work with, I’ll even write it myself).

I should also mention that the entire tunneling portion of the RFC isn’t implemented yet, so it doesn’t do things like authentication and a couple of other things that are defined in the RFC. Adobe’s proxy only uses the very basics, so that’s all I implemented for now. If there’s a demand for it, I’ll add more.

For more information on how to get your hands on the RFC2817Socket class, or any of the other Adobe open source ActionScript 3 libraries, check out the this page on the Adobe Labs wiki.

4 Responses to A Proxy-savvy Socket in ActionScript 3

  1. Franky says:

    Hello Christian,Thanks for this code!I have implemented your proxy socket class in my application but it gives a sandboxsecurity error.It seems that my app tries to connect with the proxy but Flash Player says that it s not allowed because the flash app it’s loaded from IP X and the proxy it’s in IP Y…any help?Thanks in advance,Franky

  2. Seema says:

    Hi ChristianI am not getting RFC2817Socket class . Pleasesend me a solutionThanksSeema

  3. proxyguy says:

    Does this not seem like a huge problem? With out knowledge of your proxy settings ( which 99% users will not have ) Using the socket class in AS3 is useless for production qualtiy software ( ie 99% of folks can access it ). Especially considering approx 10-20% of folks are behind some sort of proxy.

  4. Rogier says:

    Nice class, but why do you have to set the proxy info by yourself? Why does Flash still not have an option to read out Proxy settings from the current browser 🙁 This limits our possibilities extremely.