proxy issue: base URL in Settings->Admin->General changes Mime Types which causes load error

[reverendpaco]

Describe the bug
Like a lot of people I want to place metabase behind Nginx on a /metabase directory. In setting this up, I noticed a few issues like the lack of proxy awareness for site.manifest, which I worked around.

However, very much like the following: #2090 (comment) , I only got a blank page due to numerous errors of the form: Refused to execute script from ... because its MIME type ('text/html') is not executable, and strict MIME type checking is enabled.

I thought this might be an Nginx configuration issue but was able to narrow it down to metabase itself in isolation. Namely,

• when I have no directory under Settings->Admin->General-> SITE URL then the Jetty server sets the response type on the CSS and javascript correctly
• when I add a directory under Settings->Admin->General-> SITE URL, then the Jetty server sets the content type as text/html which causes the browser to refuse to execute and leaves me with a blank page

Logs

To Reproduce
Steps to reproduce the behavior:

1. Go to Settings->Admin->General-> SITE URL

2. Validate that there is no directory
   

3. Load the top page (no Nginx or proxy in play, just directly) with the network tab open and look at the response headers for app-main.bundle.js. Header type shows correct mime type
   

4. Go back to Settings->Admin->General-> SITE URL

5. Add a directory "metabase" to the Site URL
   

6. Reload the top page with the network tab open and look at the response headers for app-main.bundle.js. Header type shows incorrect mime type
   

Expected behavior
Mime type should be set correctly when base URL is changed. This should remove errors of the form:

Extra Info

1. We might explore workarounds, but wanted to get this bug in the queue sooner
2. I have tried adding a trailing slash to the directory and this did not change the issue

{
  "browser-info": {
    "language": "en-US",
    "platform": "MacIntel",
    "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.97 Safari/537.36",
    "vendor": "Google Inc."
  },
  "system-info": {
    "file.encoding": "UTF-8",
    "java.runtime.name": "OpenJDK Runtime Environment",
    "java.runtime.version": "11.0.7+10",
    "java.vendor": "AdoptOpenJDK",
    "java.vendor.url": "https://adoptopenjdk.net/",
    "java.version": "11.0.7",
    "java.vm.name": "OpenJDK 64-Bit Server VM",
    "java.vm.version": "11.0.7+10",
    "os.name": "Linux",
    "os.version": "4.14.143-91.122.amzn1.x86_64",
    "user.language": "en",
    "user.timezone": "GMT"
  },
  "metabase-info": {
    "databases": [
      "postgres",
      "h2"
    ],
    "hosting-env": "unknown",
    "application-database": "postgres",
    "application-database-details": {
      "database": {
        "name": "PostgreSQL",
        "version": "12.2 (Debian 12.2-2.pgdg100+1)"
      },
      "jdbc-driver": {
        "name": "PostgreSQL JDBC Driver",
        "version": "42.2.8"
      }
    },
    "run-mode": "prod",
    "version": {
      "date": "2020-05-28",
      "tag": "v0.35.4",
      "branch": "release-0.35.x",
      "hash": "b3080fa"
    },
    "settings": {
      "report-timezone": null
    }
  }
}

Severity
This is blocking our adoption of this current version (may try to downgrade) of metabase. We have already ruled out redash for having an antagonistic viewpoint towards proxy directory awareness. All our internal servers run with proxy awareness.

[flamber]

Hi @reverendpaco

I'm not sure what the problem is, but it seems to be related to your Nginx configuration.
You should set the Admin > Settings > General > Site URL to the path used by your users, so in your case that would be https://www.example.com/metabase

Note that in your step 6, it is correctly not loading a handful of resources, since they are actually "404" pages, which are text/html.
If you go to the URL (http://localhost:3000/metabase/app/dist/app-main.bundle.js?hash), you'll see the following, since /metabase is not a valid path in Metabase:

And then if you look at the second to last request in step 6, you'll notice that it's requesting app-main.bundle.js again, and this time from a path that is correct (http://localhost:3000/app/dist/app-main.bundle.js?hash).

Closing, since the "bug" seems to be incorrectly defined Site URL.

[mandest]

Hi @reverendpaco

I'm experiencing the same error, did you get to eventually resolve this issue or find some workaround ?

Thanks