# FastCGI A very popular deployment setup on servers like [lighttpd](http://www.lighttpd.net/) [http://www.lighttpd.net/] and [nginx](http://nginx.net/) [http://nginx.net/]is FastCGI. To use your WSGI application with any of them you will needa FastCGI server first. The most popular one is [flup](http://trac.saddi.com/flup) [http://trac.saddi.com/flup] which we will use for this guide. Makesure to have it installed. ### Creating a .fcgi file First you need to create the FastCGI server file. Let's call ityourapplication.fcgi: ~~~ #!/usr/bin/python from flup.server.fcgi import WSGIServer from yourapplication import make_app if __name__ == '__main__': application = make_app() WSGIServer(application).run() ~~~ This is enough for Apache to work, however ngingx and older versions oflighttpd need a socket to be explicitly passed to communicate with the FastCGIserver. For that to work you need to pass the path to the socket to theWSGIServer: ~~~ WSGIServer(application, bindAddress='/path/to/fcgi.sock').run() ~~~ The path has to be the exact same path you define in the serverconfig. Save the yourapplication.fcgi file somewhere you will find it again.It makes sense to have that in /var/www/yourapplication or somethingsimilar. Make sure to set the executable bit on that file so that the serverscan execute it: ~~~ # chmod +x /var/www/yourapplication/yourapplication.fcgi ~~~ ### Configuring lighttpd A basic FastCGI configuration for lighttpd looks like this: ~~~ fastcgi.server = ("/yourapplication.fcgi" => (( "socket" => "/tmp/yourapplication-fcgi.sock", "bin-path" => "/var/www/yourapplication/yourapplication.fcgi", "check-local" => "disable", "max-procs" -> 1 )) ) alias.url = ( "/static/" => "/path/to/your/static" ) url.rewrite-once = ( "^(/static.*)$" => "$1", "^(/.*)$" => "/yourapplication.fcgi$1" ~~~ Remember to enable the FastCGI, alias and rewrite modules. This configurationbinds the application to /yourapplication. If you want the application towork in the URL root you have to work around a lighttpd bug with theLighttpdCGIRootFix middleware. Make sure to apply it only if you are mounting the application the URLroot. Also, see the Lighty docs for more information on [FastCGI and Python](http://redmine.lighttpd.net/wiki/lighttpd/Docs:ModFastCGI) [http://redmine.lighttpd.net/wiki/lighttpd/Docs:ModFastCGI] (note thatexplicitly passing a socket to run() is no longer necessary). ### Configuring nginx Installing FastCGI applications on nginx is a bit tricky because by defaultsome FastCGI parameters are not properly forwarded. A basic FastCGI configuration for nginx looks like this: ~~~ location /yourapplication/ { include fastcgi_params; if ($uri ~ ^/yourapplication/(.*)?) { set $path_url $1; } fastcgi_param PATH_INFO $path_url; fastcgi_param SCRIPT_NAME /yourapplication; fastcgi_pass unix:/tmp/yourapplication-fcgi.sock; } ~~~ This configuration binds the application to /yourapplication. If you wantto have it in the URL root it's a bit easier because you don't have to figureout how to calculate PATH_INFO and SCRIPT_NAME: ~~~ location /yourapplication/ { include fastcgi_params; fastcgi_param PATH_INFO $fastcgi_script_name; fastcgi_param SCRIPT_NAME ""; fastcgi_pass unix:/tmp/yourapplication-fcgi.sock; } ~~~ Since Nginx doesn't load FastCGI apps, you have to do it by yourself. Youcan either write an init.d script for that or execute it inside a screensession: ~~~ $ screen $ /var/www/yourapplication/yourapplication.fcgi ~~~ ### Debugging FastCGI deployments tend to be hard to debug on most webservers. Very often theonly thing the server log tells you is something along the lines of “prematureend of headers”. In order to debug the application the only thing that canreally give you ideas why it breaks is switching to the correct user andexecuting the application by hand. This example assumes your application is called application.fcgi and that yourwebserver user is www-data: ~~~ $ su www-data $ cd /var/www/yourapplication $ python application.fcgi Traceback (most recent call last): File "yourapplication.fcg", line 4, in <module> ImportError: No module named yourapplication ~~~ In this case the error seems to be “yourapplication” not being on the pythonpath. Common problems are: - relative paths being used. Don't rely on the current working directory - the code depending on environment variables that are not set by theweb server. - different python interpreters being used.