Nginx

Nginx by all accounts is much more efficient than Apache, so we will probably start changing the OD server, and our server installation procedure over to Nginx. Currently (as of June 2013) we're running both Apache and Nginx with the former on ports 80 and 443 and the latter on 8080 and 8989. This way I can get the entire file structure of all sites running properly on Nginx without any change to the live sites on the standard ports. When everything is working I can switch Nginx over to the standard ports and then stop Apache and eventually un-install it completely if Nginx works out well.

Nginx uses an asynchronous event-driven approach to handling requests, instead of the Apache model that defaults to a threaded or process-oriented approach. Nginx's event-driven approach can provide more predictable performance under high loads.

Another reason we're moving over to Nginx is due to the recent interest in Perfect forward secrecy (PFS) coming from articles such as this. PFS is an obscure feature of SSL/TLS and requires at least OpenSSL version 1 and Apache version 2.3.3, but Nginx has supported it for quite some time now.

Installation

All our local installation documentation is in the install a new server procedure. The selecting a good set of ciphers section covers more detail about the perfect forward secrecy issues and installation.

Our URL rewriting rules

The OD server uses a rather complicated URL-rewriting system that allows all the wikis under all domains to run from a singe "catch-all" server block - or actually two, one for plain and one for SSL. This was quite difficult to replicate on Nginx such that it could work in exactly the same way and thereby be "web server agnostic".

Som important things to remember about Nginx request processing are:

• Only one location block will match and be processed
• The first exact match (using =) will return immediately
• Next strings will be matched, the most specific match being chosen
• Then regex matches will be chosen the first match overriding any string matches (strings can use ^~ to block the regex tests after a match)
• Rewrites at server level are evaluated before the location directives are evaluated
• Rewrites within location blocks are thenn evaluated
• If rewrites within a location block change the URI, then the locations is evaluated again
• $request_uri is the original request, $uri is updated after rewrites

Fixing PATH_INFO

The first issue I came across is that there seems to be a problem with the PATH_INFO system where Nginx can't handle URLs that request a script with a continues path such as /foo.php/bar?biz. I used KBeezie's solution which almost works, but it uses the fastcgi_split_path_info function which also seems to have a problem. It's supposed to accept a regular expression containing two captures, one gets assigned to the $fastcgi_script_name variable, and the other to $fastcgi_path_info, but for some reason the former doesn't contain the path portion of the script even if the regular expression states that it should. So in our version of KBeezie's PHP configuration I've used the following custom variables instead of $fastcgi_script_name and $fastcgi_path_info.

if ($uri ~ ^(.+\.php)(/?.*)$) { set $script $1; set $path $2; }

FastCGI parameters

The minimum required fastcgi parameters that allow a proper PHP request to be carried out are:

fastcgi_param REQUEST_METHOD $request_method; fastcgi_param CONTENT_TYPE $content_type; fastcgi_param CONTENT_LENGTH $content_length; fastcgi_param SCRIPT_NAME $fastcgi_script_name; fastcgi_param SCRIPT_FILENAME $document_root/$fastcgi_script_name;

See also

• Config example for Apache people
• Self-signed certs in Nginx
• StartSSL & Nginx
• Nginx best practices
• Nginx pitfalls
• Configuring Nginx HTTPS servers
• Installation on Debian
• Nginx variables
• The "location" directive
• Conditions and their oeprators
• Nginx rewrite module