We recently had to upgrade a Domino application server from a very outdated version. In these cases, an upgrade is not possible; instead, a new Windows server must be set up from scratch, followed by a fresh Domino installation and the transfer of all necessary .nsf files and other required data.

This wasn’t a new operation for us—we had encountered similar scenarios before—but this time, we faced an unexpected issue: the applications transferred to the new server no longer functioned correctly.

These weren’t particularly complex applications—no use of XPages or Java components. In fact, their development was clearly dated (twenty years old?) and, consequently, the technologies used were just as old. However, they had always been functional and satisfactory for the users (as is often the case with Domino applications!).

We started investigating the problem and discovered that the applications simply weren’t loading certain .js files containing JavaScript functions or .css stylesheets correctly.

Opening the application in a browser and activating the developer tools with F12, we found error messages in the console:

Refused to execute script from 'xxxxxx.js' because its MIME type ('text/html') is not executable, and strict MIME type checking is enabled.
Refused to apply style from 'xxxxxx.css' because its MIME type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking is enabled.

Since the .js and .css files weren’t being loaded, most of the application didn’t function properly.

After some research, we finally found the solution: some web applications might stop working due to the X-Content-Type-Options: nosniff header. This security feature has been included by default in HTTP responses for all Domino URLs since version 10.0.1 FP4.

Once we understood the cause, we also found a workaround: we needed to specify a variable in the notes.ini file of the Domino server so that the HTTP header would no longer include this option by default.

So, we opened the notes.ini file on the Domino server and added this line:

HTTP_DISABLE_X_CONTENT_TYPE_OPTIONS_NOSNIFF=1

After saving and restarting the Domino server, everything started working correctly again.

From a strictly theoretical standpoint, the proper solution would have been to review the application code, fix any errors, and update it to meet current standards—thus eliminating the need for this workaround. But we all know how these things go: the priority was to get everything running as quickly as possible. We can review the code later.

For now, another issue solved!

Below are the links to two documents that helped us resolve the problem:
https://support.hcl-software.com/community?id=community_question&sys_id=18caccfd1bcb2458a2f48661cd4bcb3d

https://support.hcl-software.com/csm?id=kb_article&sysparm_article=KB0077199