Follow up:
Those are the HTTP response headers that a test PHP loopback request receives:
HTTP/2 200
server: nginx
date: Fri, 15 Mar 2024 12:00:00 GMT
content-type: text/html; charset=UTF-8
vary: Accept-Encoding
link: <https://example.com/>; rel=shortlink
fastcgi-cache: MISS
strict-transport-security: max-age=31536000; ;
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
x-ua-compatible: IE=Edge
content-security-policy: frame-ancestors 'self'
x-frame-options: SAMEORIGIN
$curl = curl_init($url);
curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
curl_setopt($curl, CURLOPT_HEADER, true);
curl_setopt($curl, CURLOPT_NOBODY, true);
$response = curl_exec($curl);
curl_close($curl);
echo $response;
So I have to correct my assumption that Cache-Control: no-cache, must-revalidate, max-age=0
is added as HTTP response header, as this is set for outside requests, not for internal requests from nginx
to PHP FPM.
A related Fastcgi-Cache
HTTP header is added by Trellis, but not used by the WordPress site health check.
IMHO, the currently best approach (IMHO) would add the x-cache-enabled: true
HTTP header to requests from nginx
to PHP (fpm
):
map $upstream_cache_status $header_x_cache_enabled {
default true;
BYPASS "";
}
# Extra header for WordPress (notably its Site Health check)
add_header X-Cache-Enabled $header_x_cache_enabled;
(A fitting place can be after the aforementioned Fastcgi-Cache
header directive, the map would be set before the server
block).
For extending the configuration template:
(nginx-includes/wordpress-site.conf.child
):
{% extends 'roles/wordpress-setup/templates/wordpress-site.conf.j2' %}
{% block server_before -%}
{{ super() }}
map $upstream_cache_status $header_x_cache_enabled {
default true;
BYPASS "";
}
{%- endblock %}
{% block server_basic %}
{{ super() }}
# Extra header for WordPress (notably its Site Health check)
add_header X-Cache-Enabled $header_x_cache_enabled;
{% endblock -%}
(group_vars/all/main.yml
or environment-specific main.yml
):
nginx_wordpress_site_conf: nginx-includes/wordpress-site.conf.child
Adding this to Trellis by default appears to be a good idea (no obvious side-effects, improving compatibility with WordPress core (site health check)).
Would this be also worth a WordPress core trac issue, that the Fastcgi-Cache
HTTP response header is also used as page cache indication in the WordPress site health check?