So, OpenMRS has some files that are served with the incorrect MIME type. This basically means that the response for those resources contains a header called Content-Type
with a value that is not a valid Javascript MIME type (in this case text/plain
and text/html
). While this is less than ideal, for the most part this doesn’t cause issues. If you investigate, f/e demo.openmrs.org and open the network tab of your browser, you’ll see the same files that are raising errors here are served with the same MIME types, but aren’t blocked from executing by your browser (it shows up as a console warning rather than a console error). By default browsers try to be forgiving.
However, if your server sets the header X-Content-Type-Options: nosniff
on the response for those resources (which seems to be what’s happening here), the browser uses “strict MIME type checking”, which means that it will only allow a file referenced from a script
tag to be executed as a script if the MIME type is one recognised as a Javascript MIME type.
In other words, in the HTML for the Concept Dictionary Maintenance page you will find a tag like this:
<script src="/openmrs/scripts/openmrsmessages.js?v=2.5.9&locale=en_GB" type="text/javascript" ></script>
But when the browser downloads that file, it gets a response something like this:
HTTP/1.1 200
Server: nginx/1.18.0 (Ubuntu)
Date: Thu, 13 Apr 2023 14:46:34 GMT
Content-Type: text/html;charset=UTF-8
Content-Length: 3479
Connection: keep-alive
Last-Modified: Thu, 13 Apr 2023 13:03:21 GMT
Content-Language: en-GB
Strict-Transport-Security: max-age=15768000
X-Content-Type-Options: nosniff
<CONTENT OF THE FILE>
Since the Content-Type
here is text/html
, which is not a valid Javascript MIME Type the browser blocks the execution of that script (and a couple of others). Unfortunately, those scripts are necessary for the Conception Dictionary search to function, so if they don’t execute (as in this case) you’re stuck looking at a page like that.
By default, nothing in OpenMRS sets the X-Content-Type-Options
header. This is done somewhere in the configuration of your application, either, e.g., as something adding to the Tomcat configuration or maybe you’re running a server like Apache or Nginx in front of OpenMRS and it is adding this header.
The issue of scripts being served with the wrong MIME type is tracked in this ticket, but, unfortunately, it hasn’t been resolved yet. Presumably waiting for that ticket to be resolved is going to cause an unacceptable delay in your go-live, so here are some things you can do:
- Remove the rule that is setting the
X-Content-Type-Options
header.
- Selectively remove the rule that is setting the
X-Content-Type-Options
header only for the files that are showing up as errors in the console logs in your screenshots.
- Add a rule to the server that you’re running in front of OpenMRS ensure that
.js
files are served with the MIME type application/javascript
For example, if you are using nginx in front of OpenMRS (I’m more familiar with nginx than Apache; the idea should be the same and the directives should be similar, but the syntax is somewhat different), you might have a configuration like this:
# snip
http {
# snip
server {
listen 443 ssl;
# more configuration
add_header X-Content-Type-Options nosniff; # obey the MIME type
proxy_pass http://openmrs:8080;
}
}
Then you could add, before the proxy_pass
rule something like the following configuration to serve those files with an appropriate MIME type:
location = /openmrs/dwr/interface/DWRAlertService.js {
proxy_pass http://openmrs:8080;
proxy_hide_header Content-Type;
add_header Content-Type "application/javascript";
}
location = /openmrs/dwr/interface/DWRConceptService.js {
proxy_pass http://openmrs:8080;
proxy_hide_header Content-Type;
add_header Content-Type "application/javascript";
}
location = /openmrs/scripts/openmrsmessages.js {
proxy_pass http://openmrs:8080;
proxy_hide_header Content-Type;
add_header Content-Type "application/javascript";
}