It's relatively obvious how to deploy a WSGI application using Nginx, and there are many tutorials out there dealing with this very task. It took me quite a few minutes, however, to figure out how to deploy the application under non-root URL, e.g.
This is typically dealt with by configuring the
SCRIPT_NAME CGI parameter, and letting this name be removed from the beginning of the
PATH_INFO parameter by the WSGI environment, before the path is passed down to the application. This way the WSGI application routing remains the same, no matter where in the URL tree it is deployed. The application needs to be aware of
SCRIPT_NAME parameter only to generate proper URLs to self. Continue reading…
It seems that my patch for the Cherokee redirect handler's
SIGSEGV problem has been accepted. That's exactly what I love about open-source software - instead of waiting for the software vendor to fix the problem I can do the correction myself. Just released Cherokee 1.0.9 doesn't contain the fix yet, though, it's going to be included in the next release.
I've been using Apache for many years now, thus recently I've made a decision to try some of the "new" web servers. One of my hosts runs lighttpd for quite some time without any problems, so this time I wanted to try something else. Cherokee has caught my attention, thanks to it's web-based configuration utility - it is intuitive enough to go without reading the documentation really.
Indeed, configuring my site has taken about 15 minutes - HTTP to HTTPS redirection, WSGI application, PHP5 - all up and running. But... I've noticed that HTTP to HTTPS redirection fails occasionally for no obvious reason. It quickly turned out that the server's worker process dies of segmentation fault. Source code investigation led to a quick patch and an issue reported. Not really a perfect first impression, huh? Time to try nginx, I guess... 😉
For various (mostly security) reasons I prefer to deploy Django applications as separate processes, with web server and actual application running under different UIDs, communicating with each other via FastCGI or SCGI socket. This way application is safer from e.g. vulnerable PHP scripts running within the web server process - it's pretty common for the attackers to use PHP vulnerabilities to read files accessible by the web server itself (for smaller sites it's normal to use a single web server installation for many different applications). Continue reading…