We’ve got an establish Apache/PHP site, with a Flash front-end. We’re going to start to need to implement some sort of socket communication, or ‘long-polling’, to push updates to the flash app. Since this obviously isn’t going to be a good situation for Apache, or PHP, I’d like to use Tornado for this aspect of the functionality, but I also don’t want to run Tornado on another port, since the Flash app will be running on the client machine, we don’t want to have to deal with restrictive firewalls blocking the socket connections.
Ideally I’d like to run a proxy which can forward most requests to Apache, and other requests to Tornado. I saw some suggestions for using Apache as the first-contact proxy, forward requests to Tornado when necessary, but I’ve also seen this discounts a lot of the async capabilities of Tornado.
I thought, why no use Tornado as the first-contact for port 80 and have it proxy back to Apache? I couldn’t find anything on this at all and am wondering if this is even possible?
Another option would be to use something like lighttpd as the proxy and have it decide whether to pass things along to Apache or to Tornado, but does this kind of setup make sense? Or what about Nginx?
Any suggestions, advice or corrections on my understanding of things would be greatly appreciated!
This is called a reverse proxy and it’s very easy to configure nginx to perform this. (lighttpd should also be able to do this job well, but I have no experience using it).
The tornado documentation has an example nginx configuration
One thing to note when using a reverse proxy is that the connection to your upstream server will now be originating from the proxy, not the client. The de facto standard is to put information about the original request in certain http headers. In the example from the tornado docs, the X-Real-IP header is set to the IP of the original client and X-Scheme is set to the scheme of the original request (http/https for example).
This may require some modifications to your upstream server. With tornado this is done by constructing the HTTPServer with the xheaders argument set to True. This will instruct the server to try and pull the IP address and scheme from the X-headers. Note that if you use this with a server that isn’t behind a reverse proxy that sets the appropriate headers than you are open to IP Address spoofing.