NGINX SSI with Symfony and PHP-FPM

I'm sharing the solution I previously gave you in private, so everybody can have access to it.

1. First of all, since you are using fastcgi, you must use the fastcgi_cache_* directives,

for example:

fastcgi_cache_path  /tmp/nginx  levels=1:2  keys_zone=foobar:10m;

instead of

proxy_cache_path    /tmp/nginx  levels=1:2  keys_zone=foobar:10m;

2. Since Symfony identifies the ssi fragments with an unique query string, you must include the query string in the cache key parameter,

otherwise you would always cache the entire page. You can use:

fastcgi_cache_key   $scheme://$host$saved_uri$is_args$args;

3. From your code on https://github.com/alessandro-candon/ssi-symfony,

I see you call:

http://localhost:8101/home

It would match the "/" location, then nginx would make an internal request to ^/index.php(/|$)

The problem is, in this way the current $uri variable will be changed to "index.php", so you are losing "/home" and can't pass it anymore to Symfony (where it is handled by the Symfony routing). To solve this, save it to a custom nginx variable:

set $saved_uri $uri;

then, pass it to fastcgi:

fastcgi_param REQUEST_URI  $saved_uri;

NOTE By default the REQUEST_URI fastcgi param is set to $request_uri. If you don't change it, Symfony will always receive the path provided by curl ("/home") for the ssi fragments requests too! Therefore you'll get an infinite loop when solving the ssi includes. (see: Wrong cache key for SSI-subrequests with FastCGI)

I suggest you to include the default fastcgi_params asap, so you can override them later. If you put include fastcgi_params at the bottom of you configuration, your custom values would be overridden by the default ones.

4. You must also consider that when doing an internal request for the ssi inclusion, nginx does not update the $uri variable. To solve this, explicitly update it. (NOTE: Here i'm using $saved_uri instead of $uri because of the problem described before). Assuming you are using _fragment to identify the path for your ssi fregments generated by Symfony,

you need to add:

set $saved_uri /_fragment;

5. About the SSI header: to tell to Symfony that nginx has got ssi enabled, the ssi on directive is not enough, because nginx doesn't automatically send the Surrogate-Capability: device="SSI/1.0" header to Symfony.

To do so, use:

fastcgi_param HTTP_SURROGATE_CAPABILITY "device=\"SSI/1.0\"";

6. Last but not least, remember that defining the cache path is not enough,

you also need to tell nginx to use it:

fastcgi_cache foobar;

In conclusion, the complete configuration will be:

fastcgi_cache_path  /tmp/nginx  levels=1:2  keys_zone=foobar:10m;
fastcgi_cache_key   $scheme://$host$saved_uri$is_args$args;  # The query string must be used here too, because Symfony uses it to identify the ssi fragment

server {
    listen 80;
    root /var/www/html/symfony/public;
    client_max_body_size 40M;

    include fastcgi_params;  # We must put this here ahead, to let locations override the params

    location = /health {
        return 200 "healthy\n";
    }

    location = /ping {
        return 200 "pong\n";
    }

    location /_fragment {
        set $saved_uri /_fragment;  # We hardcode the value because internal ssi requests DO NOT update the $uri variable !
        try_files $uri /index.php$is_args$args;
        internal;
    }

    location / {
         set $saved_uri $uri;  # We need this because the $uri is renamed later when making the internal request towards "index.php", so we would lose the original request !
         try_files $uri /index.php$is_args$args;
    }

    location ~ ^/index\.php(/|$) {

        fastcgi_cache foobar;  # Remember to not use the directive "proxy_cache" fastcgi
        add_header X-Cache-Status $upstream_cache_status;  # Used for debugging
                                                           # NOTE nginx<->Symfony cache is NOT considered in this

        fastcgi_param HTTP_SURROGATE_CAPABILITY "device=\"SSI/1.0\"";  # Nginx doesn't pass this http header to Symfony even if ssi is on, but Symfony needs it to know if the proxy is able to use ssi
        ssi on;

        fastcgi_param REQUEST_URI  $saved_uri;  # IMPORTANT The included default "fastcgi_params" uses $request_uri, so internal requests are skipped ! This causes an infinite loop because of ssi inclusion.
        fastcgi_param QUERY_STRING $args;  # For some reason, we need to pass it again even if the included default "fastcgi_params" looks correct

        fastcgi_pass php-fpm:9000;
        fastcgi_split_path_info ^(.+\.php)(/.*)$;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param DOCUMENT_ROOT   $document_root;
        fastcgi_param REQUEST_METHOD  $request_method;
        fastcgi_param CONTENT_TYPE    $content_type;
        fastcgi_param CONTENT_LENGTH  $content_length;
        fastcgi_read_timeout 300;
        internal;
    }

    location ~ \.php$ {
        return 404;
    }

    location /status {
        access_log off;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass php-fpm:9000;
        fastcgi_index status.html;
    }

    error_log /var/log/nginx/error.log;
    access_log /var/log/nginx/access.log;
}