nginx’s a pretty powerful server, no doubt. But depending on your situation, a simple caching solution as discussed in my FastCGI Caching Basics article might not be enough, or may outright break your setup. You may also want nginx to co-exist with any existing application cache as well.
In this article, I’ll explain a few techniques that can be used to help alter nginx’s caching and proxy behaviour to get the configuration you need.
Advanced use of fastcgi_param
fastcgi_param is an important part of setting up the environment for proper operation. It can also be used to manipulate the HTTP request as it is being passed to the backend, performing an ad-hoc mangling of the request.
Example: clearing the Accept-Encoding request header
fastcgi_param HTTP_ACCEPT_ENCODING "";
This is useful when an application is configured to send a response deflated, ie: with gzip compression. This is something that should be handled in nginx, not the backend, and caching a gzipped response with a key that may cause it to be sent to a client that does not support compression will obviously cause problems. Of course, this should probably be turned off in the application, but there may be situations where that is not possible. This effectively clears whatever was set here in the first place, possibly by something earlier in the config.
Ignoring and Excluding Headers
Via fastcgi_ignore_headers and fastcgi_hide_header, one can manipulate the headers passed to the client and even control nginx’s behaviour itself.
Example: Ignoring Cache-Control
Imagine a scenario where the application you are using has a caching feature that can be used to compliment nginx’s own cache by speeding up updates, further reducing load. However, this feature sends Cache-Control and Expires headers. nginx honours these headers, which may manipulate nginx’s cache in a way you do not want.
This can be corrected via:
fastcgi_ignore_headers Cache-Control Expires; fastcgi_hide_header Cache-Control; fastcgi_hide_header Expires;
This does the following:
- The
fastcgi_ignore_headersline will ensure that nginx will not honor any data in theCache-ControlandExpiresheader. Hence, if caching is enabled, nginx will cache the page even if there is aCache-Control: no-cacheheader. Additionally,Expiresfrom the response is ignored as well. - However, with this on, the response will still be passed to the client with the bad headers. That is probably not what is desired, so
fastcgi_hide_headeris used to ensure that those headers are not passed to the client as well.
Gotcha #1: Ensuring an Admin Area is not Cached
If the above techniques are employed to further optimize the cache, then it is probably a good idea to ensure that the admin area is not cached, explicitly, if Cache-Control was relied on to do that job before.
Below is an example on how to structure that in a config file, employing all of the other items that I have discussed already. Note that static entry of the SCRIPT_FILENAME and SCRIPT_NAME is probably necessary for the admin area, as the dynamic location block for general PHP files will have the caching credentials in it.
# fastcgi for admin area (no cache)
location ~ ^/admin.* {
include fastcgi_params;
# Clear the Accept-Encoding header to ensure response is not zipped
fastcgi_param HTTP_ACCEPT_ENCODING "";
fastcgi_pass unix:/var/run/php5-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root/index.php;
fastcgi_param SCRIPT_NAME /index.php;
}
location / {
try_files $uri $uri/ /index.php$is_args$args;
}
# Standard fastcgi (caching)
location ~ \.php$ {
include fastcgi_params;
# Clear the Accept-Encoding header to ensure response is not zipped
fastcgi_param HTTP_ACCEPT_ENCODING "";
fastcgi_ignore_headers Cache-Control Expires;
fastcgi_hide_header Cache-Control;
fastcgi_hide_header Expires;
fastcgi_pass unix:/var/run/php5-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_cache fcgi_one;
fastcgi_cache_valid 200 1m;
fastcgi_cache_key $request_method-$http_host$fastcgi_script_name$request_uri;
fastcgi_cache_lock on;
fastcgi_cache_use_stale error timeout invalid_header updating http_500 http_503;
}
This setup will route all requests for /admin to FastCGI with a statically defined page and no cache options. This will ensure that no caching and header manipulation happens, while regular FastCGI requests will be sent to the optimized block with the caching and header bypass features.
Note the fastcgi_cache_key. This is the last thing I want to talk about:
Gotcha #2: Caching and HEAD Requests
nginx’s fastcgi_cache_key option does not have a default value, or at least the docs do not give one. The example may also be insufficient for everyday needs, or at least I thought it was. However, the proxy_cache_key has the following default value:
scheme$proxy_host$uri$is_args$args
This was pretty close to what I needed initially, and I just altered it to $http_host$fastcgi_script_name$request_uri. However, when I put this config into production, we started seeing the occasional blank page, and our monitors were reporting timeouts. It took quite a bit of digging to find out that some of our cache entires were blank, and a little googling later ended up revealing the obvious, which was confirmed in logs: HEAD requests were coming thru when there was no cache data, and nginx was caching this to a key that could not discern between a HEAD and a GET request.
There are a couple of options here: use fastcgi_cache_methods to restrict caching to only GET requests, or add the request method into the cache key. I chose the latter, as HEAD requests in my instance caused just as much load as GET requests, and I would rather not run into a situation where we encounter load issues because the servers are hammered with HEAD requests.
The new cache key is below:
fastcgi_cache_key $request_method-$http_host$fastcgi_script_name$request_uri;
vancluevertech.com 