fix(htaccess): serve .json and .ftl files statically instead of routing them to the front controller

[ByteSide]

• Resolves: [Bug]: PDF viewer broken due to .json and .ftl rewrite rules #63512

Summary

The bundled pdf.js of files_pdfviewer loads its localization from apps/files_pdfviewer/js/pdfjs/web/locale/locale.json and apps/files_pdfviewer/js/pdfjs/web/locale/<lang>/viewer.ftl.

Neither json nor ftl is part of the static file exclusion of the front controller rule that Setup::updateHtaccess() writes when pretty URLs are enabled, so Apache routes both requests to index.php, which answers 404. pdf.js then fails to initialize and renders its alt text dialog instead of the document.

Both extensions are added to that exclusion.

Why this does not widen what is reachable

.json and .ftl are already served statically in the two other supported setups:

• our nginx reference configuration falls through to try_files $uri $uri/ /index.php$request_uri, so both are served there today
• an Apache instance without pretty URLs never gets the rewrite to the front controller in the first place, so both are served there today as well

Only Apache with pretty URLs behaves differently, and this change aligns it with the other two.

The one thing the nginx configuration does deny explicitly is package manager metadata:

location ~ ^/(?:composer\.(?:json|lock)|package(?:-lock)?\.json|core/shipped\.json)$ { return 404; }

.htaccess has no equivalent, because with pretty URLs those paths happened to be swallowed by the front controller rule, and without pretty URLs they were reachable regardless. The same rule is therefore added to .htaccess, so that this change serves nothing that nginx would not serve, and the gap for installations without pretty URLs is closed along the way.

Happy to drop that second hunk if you would rather keep this to the one-line fix.

Notes

• This is the same class of bug as [Bug]: PDF viewer broken due to .json and .ftl rewrite rules #63512's predecessor for locale.properties (Files_pdfviewer : localisation doesn't work with NC 29.0.7 files_pdfviewer#1191, PR fix: add properties files to htaccess rewrite condition #48692, closed without a merge). Upstream pdf.js has since moved to Fluent, which is why it is locale.json and viewer.ftl now rather than locale.properties.
• The extension list exists only in lib/private/Setup.php; no test asserts its content.
• The root .htaccess is hashed only up to #### DO NOT CHANGE ANYTHING ABOVE THIS LINE #### by the integrity checker, and core/signature.json is generated at release time, so no signature needs regenerating here.
• The nginx reference configuration in nextcloud/documentation already handles both extensions correctly, so no documentation change is required.

Testing

Reproduction, curl output before/after and confirmation that the viewer works again are in #63512; the report was independently confirmed for 34.0.3 and 33.0.8.

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests are included — not applicable, this is a webserver configuration change with no test harness for the generated .htaccess
• Screenshots before/after for front-end changes — not applicable
• Documentation has been updated or is not required
• Backports requested where applicable — please backport to stable34 and stable33 if you agree, the issue is confirmed on both
• Labels added where applicable
• Milestone added for target branch/version

[joshtrichards]

I'm not sure adding all these exceptions is the best approach in the long run. Besides leading to a de facto "default allow" policy (for the involved extensions), which could bite us if we're not careful... It's also a maintenance headache to keep requiring customization of web server configurations.

Other apps, such as Nextcloud Office, which have to serve a fonts.json as well as individual font files, I think implement controllers which serve the assets. Means assets are also still within the confines of whatever is deemed appropriate within the Nextcloud framework to be applicable (i.e. being authenticated, rare limiting, etc.)

https://github.com/nextcloud/richdocuments/blob/78d2e1f9700b6de455905a033905cc10b6d4955d/lib/Controller/SettingsController.php#L381

We could also make this way easier by implementing a counterpart to addScript() and the like but for more general assets.

Thinking out loud here... I don't have a formal solution in mind at the moment. Just my gut and some random thoughts.