Unstyled pages after upgrade to 3.3.0~ynh4

[clawfire]

Describe the bug

After an upgrade from version 3.3.0~ynh3 to version 3.3.0~ynh4 using the web admin panel upgrade, the pages looked unstyled just like in #267 .

Context

• Hardware: Gandi VPS
• YunoHost version: 4.2.5.2
• I have access to my server: Through SSH & through the yunohost webadmin
• Are you in a special context or did you perform some particular tweaking on your YunoHost instance?: no
• The upgrade (which went fine) log can be found here https://paste.yunohost.org/raw/ugerededeb

The errors

All the assets seems to be 404. Which leads to a complete blank page for the web client and a unstyled pages for login and admin as described in #267

The web client :

The web client profile :

But accessing it through an app (like Tusky on my android phone) is working just fine.

[clawfire]

As said here https://github.com/YunoHost-Apps/mastodon_ynh/issues/267#issuecomment-850972905, I tried to solve it the same way that #267 was solved but didn't work

[binarydad]

I was just about to post regarding this exact issue.

Firefox - works when visiting page, works with hitting F5, but breaks when doing Ctrl+F5 Chrome - does not work at all Edge - works when hitting F5, breaks when doing Ctrl+F5

When comparing similar requests to other Mastodon sites, I noticed there are a lot of extra headers in the response. One that seems interesting is x-content-type-options: nosniff, which is noted in a warning (see below). These particular files (css and JS files) don't appear to have a "type" associated with the tag.

When picking a random (404'd) resource on my instance and comparing it against the same on fosstodon.org, I see this:

My site

URL: https://social.binarydad.com/packs/css/common-3623162d.css

Response header: (note, this is 200 OK because I loaded the page directly)

HTTP/1.1 200 OK server: nginx date: Fri, 26 Feb 2021 21:32:39 GMT content-type: text/css content-length: 29335 last-modified: Fri, 26 Feb 2021 21:12:54 GMT x-sso-wat: You've just been SSOed etag: "60396456-7297" content-security-policy: upgrade-insecure-requests content-security-policy-report-only: default-src https: data: 'unsafe-inline' 'unsafe-eval' x-content-type-options: nosniff x-xss-protection: 1; mode=block x-download-options: noopen x-permitted-cross-domain-policies: none x-frame-options: SAMEORIGIN strict-transport-security: max-age=31536000 cache-control: public, max-age=31536000, immutable accept-ranges: bytes X-Firefox-Spdy: h2

Fosstodon

URL: https://fosstodon.org/packs/css/common-6632dedd.css

Response header:

HTTP/1.1 200 OK Date: Wed, 09 Jun 2021 13:49:10 GMT Content-Type: text/css Transfer-Encoding: chunked Connection: keep-alive Vary: Accept-Encoding Last-Modified: Thu, 03 Jun 2021 10:31:11 GMT Strict-Transport-Security: max-age=63072000; includeSubDomains Content-Encoding: gzip

Firefox seems to give some info on this. This is for another file, but it also is 404'd. Seems something to do with the "nosniff" header?

The resource from “https://social.binarydad.com/packs/js/common-a34d4fc19bd4731b9983.js” was blocked due to MIME type (“”) mismatch (X-Content-Type-Options: nosniff)

[weex]

As said here #267 (comment), I tried to solve it the same way that #267 was solved but didn't work

Does yunohost use a particular user for each app? If so, you might need to su - username over to that account because ruby at least is definitely accessible to the Mastodon serving process.

[binarydad]

Is there any way to remove some of these headers that Nginx (or the app itself?) is putting into the response?

[binarydad]

This appears to be fixed with the 3.4.1 update! Thank you!!

I'm rather curious... what caused the issue? I thought it was the "nosniff" response header but that appears to still be there. Thanks!

[ghost]

Same problem occurs as of 3.4.4~ynh1 on my instance.

However, it is related to Reverse Proxying with Cloudflare. Firefox returns a blank page with Javascript error saying hashes in the integrity attribute match the content of the subresource. if a CDN/reverse-proxy is turned on.

The workaround is to turn off Cloudflare proxying and run commands from #267 with npx upgraded.