Nextcloud theme broken after upgrade v9.1.1

Jep that’s it. Pure stupidity IMO, as if someone would want to have ALL MIME types for ALL file extensions busted when defining it for a single additional file extension within a location or server block. While for add_header, the same nasty behaviour is at least documented, for types I could not find a single hint about it, instead I even find lots of guides who do exactly this: define a single MIME type within a location block. And whatever I search for regarding location and/or server blocks overwriting parent types, I do not find a single matching entry, docs, blog of forum post about this …

Since we must serve mjs as JavaScript type for Nextcloud to function, we must additionally include the whole default types file above this block, while it is already included in the http block of /etc/nginx/nginx.conf

sed -i '/types {/i\\tinclude mime.types;' /etc/nginx/sites-dietpi/dietpi-nextcloud.conf
systemctl restart nginx

You need to do an active (F5) of forced (CTRL+F5) page reload for the change to become effective.

I really can’t understand why Nginx behaves like this. This is so totally non-intuitive to me and means a lot of doubled definitions. We also need to add all security headers 3 times: In the default/parent config, within the Nextcloud location block and again within the sub-location block for Nextcloud assets, only because those have additionally a Cache-Control header set. Nextcloud’s official/documented Nginx config provided in their docs tapped into the same trap and served all assets without any security/privacy header for 2 years, until I found this recently when updating our Nginx config and fixed it. So it is not only me but I find this all the time in various documented Nginx configs across various software projects. This is not only an unnecessary additional maintenance and coding burden, but a security issue as well. Enough for this rant for today :smile:

I’ll set up a live patch to have this fixed for everyone.

3 Likes