nginx vhosts directive impedes automatic thumbnail generation

gaekwad · Yesterday 09:38:56

jakob wrote #342007:

I think I’ve identified it as a problem in the default nginx vhost that I don’t quite understand yet.

It has a section as follows:

location ~* ^.+\.(css|js|jpg|jpeg|gif|png|ico|gz|svg|svgz|ttf|otf|woff|woff2|eot|mp4|ogg|ogv|webm|webp|zip|swf|map|mjs)$ {...

Removing jpg|jpeg from that list allows the images to appear. I need to learn what that means and then see what I should correct or exclude from that. But that’s a problem for tomorrow.

EDIT: Additional observations after further investigation:

Normal images seem to be handled just fine, so it looks like just the initial redirect to thumbnail creation situation that occurs when a token is passed isn’t being handled. To test that, I temporarily removed the image extensions from that list allows txp to create the thumbs, then restored the original nginx directive including the image extensions. The thumbnails created in the /images/thumb/…directories now work, just the new creation of thumbs doesn’t.

gaekward or anyone else? Is there a way of either passing through image requests that result in a 404 or 301 to the thumbnail creation routine, and / or is there a way of excluding location regexs that contain a ?token=@ url parameter from this directive?

Is there any chance you can split this to / start another topic and post your full (anonymised) Nginx config, please?

jakob · Yesterday 15:14:25

Thanks Pete. This is with a Hetzner VPS of the kind you recommended but using www.cloudpanel.io as a control panel rather than setting up the entire stack myself. You can create multiple sites with a chosen PHP version and own database(s), and so on. It’s relatively straightforward to use and exposes a portion of the nginx config as an editable vhost entry. There’s a demo on their site. When you create a new site, you can choose from a number of different presets which come with different vhost templates. Textpattern isn’t (yet) one of those, so I chose Generic PHP.

This is the vhost. You can see there are some placeholders where particular content is injected from the settings elsewhere in the site config settings:

server {
  listen 80;
  listen [::]:80;
  listen 443 quic;
  listen 443 ssl;
  listen [::]:443 quic;
  listen [::]:443 ssl;
  http2 on;
  http3 off;
  {{ssl_certificate_key}}
  {{ssl_certificate}}
  server_name www.mydomain.com;
  return 301 https://mydomain.com$request_uri;
}

server {
  listen 80;
  listen [::]:80;
  listen 443 quic;
  listen 443 ssl;
  listen [::]:443 quic;
  listen [::]:443 ssl;
  http2 on;
  http3 off;
  {{ssl_certificate_key}}
  {{ssl_certificate}}
  server_name mydomain.com www1.mydomain.com;
  {{root}}

  {{nginx_access_log}}
  {{nginx_error_log}}

  if ($scheme != "https") {
    rewrite ^ https://$host$request_uri permanent;
  }

  location ~ /.well-known {
    auth_basic off;
    allow all;
  }

  {{settings}}

  location / {
    {{varnish_proxy_pass}}
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_hide_header X-Varnish;
    proxy_redirect off;
    proxy_max_temp_file_size 0;
    proxy_connect_timeout      720;
    proxy_send_timeout         720;
    proxy_read_timeout         720;
    proxy_buffer_size          128k;
    proxy_buffers              4 256k;
    proxy_busy_buffers_size    256k;
    proxy_temp_file_write_size 256k;
  }

  # location ~* ^.+\.(css|js|jpg|jpeg|gif|png|ico|gz|svg|svgz|ttf|otf|woff|woff2|eot|mp4|ogg|ogv|webm|webp|zip|swf|map|mjs)$ {
  location ~* ^.+\.(css|js|ico|gz|svg|svgz|ttf|otf|woff|woff2|eot|mp4|ogg|ogv|webm|zip|swf|map|mjs)$ {
    add_header Access-Control-Allow-Origin "*";
    add_header alt-svc 'h3=":443"; ma=86400';
    expires max;
    access_log off;
  }

  location ~ /\.(ht|svn|git) {
    deny all;
  }

  if (-f $request_filename) {
    break;
  }
}

server {
  listen 8080;
  listen [::]:8080;
  server_name mydomain.com www1.mydomain.com;
  {{root}}

  include /etc/nginx/global_settings;

  try_files $uri $uri/ /index.php?$args;
  index index.php index.html;

  location ~ \.php$ {
    include fastcgi_params;
    fastcgi_intercept_errors on;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    try_files $uri =404;
    fastcgi_read_timeout 3600;
    fastcgi_send_timeout 3600;
    fastcgi_param HTTPS "on";
    fastcgi_param SERVER_PORT 443;
    fastcgi_pass 127.0.0.1:{{php_fpm_port}};
    fastcgi_param PHP_VALUE "{{php_settings}}";
  }

  if (-f $request_filename) {
    break;
  }
}

The part that is causing problems is this section:

  # location ~* ^.+\.(css|js|jpg|jpeg|gif|png|ico|gz|svg|svgz|ttf|otf|woff|woff2|eot|mp4|ogg|ogv|webm|webp|zip|swf|map|mjs)$ {
  location ~* ^.+\.(css|js|ico|gz|svg|svgz|ttf|otf|woff|woff2|eot|mp4|ogg|ogv|webm|zip|swf|map|mjs)$ {
    add_header Access-Control-Allow-Origin "*";
    add_header alt-svc 'h3=":443"; ma=86400';
    expires max;
    access_log off;
  }

From what I can tell, this isn’t anything particularly unusual and mostly has to do with access to, logging of and long-term browser caching duration of static assets, e.g. images, fonts, scripts, stylesheets, video files, etc. The regex isn’t particularly complex either.

A regular Textpattern installation with user or system-generated pre-created thumbnails works fine with this. It’s only when you come to automatic thumbnail generation that the original directive (the one commented out) blocks display of those thumbnails. Removing the relevant image types from the list of extensions (as above) restores functionality. I guess the penalty of me omitting image types from the list of assets is reduced long-term browser caching of images.

I think (but am not entirely sure) that the problem has to do with the way the generation of automatic thumbnails is triggered: if I’ve understood it correctly, if the browser asks for an image that doesn’t yet exist, Textpattern intercepts the 404 returned, generates the image and then passes back a 301 to the server to report its new location. Somewhere during that, nginx loses track of the headers. I tried debugging this with copilot’s help but got quite lost with the description.

gaekwad · Yesterday 16:24:35

Some interesting stuff in that Nginx config…

listen 443 quic;
listen [::]:443 quic;
[…]
http3 off;

Arm port 443 on IPv4 and IPv6 for QUIC (which is HTTP/3-only)…and then disable HTTP/3. So QUIC won’t work.

You can comment out this line later in the location block:

add_header alt-svc 'h3=":443"; ma=86400';

…since HTTP/3 appears to be off anyway, that header is redundant.

I’ll have a look ^{to actually try and answer your question} with fresh eyes at a later time…long day so far and some firefighting has caught be off guard.

gaekwad · Yesterday 16:26:00

add_header Access-Control-Allow-Origin "*";

Quick test – try this instead:

add_header Access-Control-Allow-Origin "*" always;

…to force it.

jakob · Yesterday 17:24:05

gaekwad wrote #342313:

Arm port 443 on IPv4 and IPv6 for QUIC (which is HTTP/3-only)…and then disable HTTP/3. So QUIC won’t work …since HTTP/3 appears to be off anyway, that header is redundant.

I think it’s in there so that people can choose to enable HTTP/3: it’s described here. Presumably the other directives do nothing if http3 is off.

Textpattern CMS

Textpattern CMS support forum

#1 Yesterday 09:38:56