Error loading pdf-viewer on vps server

[bryanwac]

Got this error after uploading my frontend to a vps, cant open files and viewer do not even load.

Error: Failed to load module script: Expected a JavaScript module script but the server responded with a MIME type of "". Strict MIME type checking is enforced for module scripts per HTML spec.

Local machine:

VPS machine:

Does anyone have faced this or can help me with?

[bryanwac]

btw, this are already on my angular,json

[bryanwac]

Also, added the mime types to apache mime conf: .js and .mjs

[stephanrauh]

You've already found the solution that helped several other developers. The error message indicates your apache configuration doesn't work yet. Maybe it's not active for some reason?

<IfModule mod_mime.c>
  AddType text/javascript js mjs
</IfModule>

[bryanwac]

I solved the problem by using ng build --configuration test and not ng build.

[jpathman]

@bryanwac what was the configuration in "test" that resolved your issue? I believe I have the exact same problem where the pdf does not render and I have the console error mentioning something about the pdf min mjs

[bryanwac]

@jpathman Basically, you need this object in your "assets" config, because when u run the ng build, the app try to find the file in the node_modules folder, and it does not exists, because app can handle the "ngx-extended-pdf-viewer/assets/" in localhost.

Using ur test/prod config to build the app, transfer the files from node_modules to assets, and tell the app to look there for the viewer files.

[jpathman]

@bryanwac @stephanrauh

What's odd is that for me I already have this line in my configuration. We've been using ngx-extended-pdf-viewer version 5.2.1 for a long time and it's been working locally and in deployed for a long time. Once we migrated to angular 16 we started getting ivy related errors with npm install so we updated the ngx-extended-pdf-viewer to 19.3.0. It works locally but doesn't work when in a deployed environment! The console just complains about the pdf min mjs in the deployed environment similar to the screenshots in this issue.

[stephanrauh]

I still think the most likely cause it a wrong MIME type configuration. If it works correctly, you can see it in the network tab:

[jpathman]

@stephanrauh The content type I get in network is application/octet-stream. Does that mean I need to do extra configurations around Mime type using nginx? Is there any other work arounds?

[stephanrauh]

Yes, you need the additional configuration. Don't ask me why nginx doesn't ship the *.mjs MIME type by default. It doesn't make sense to me - mjs files aren't exactly new, they've been around for years.

Be that as it may, I'm not aware of any workaround, so you need to add something like this:

include mime.types;  // <<< this is probably already there - you may not need it
  types {
      application/javascript mjs;
  }

[stephanrauh]

Off topic: I was puzzled by the word "octet stream", because octet is the French word for byte, and I've never seen it outside France. Here's the answer of my good friend ChatGPT:

The term "octet stream" is used instead of "byte stream" in certain contexts to emphasize the precision of the data unit being referred to. Specifically, an "octet" is a term used to describe a unit of digital information that consists of eight bits. The key reason for using "octet" instead of "byte" is that an octet is always eight bits, whereas the size of a "byte" can technically vary depending on the system or architecture, even though in modern computing, a byte is almost universally eight bits as well.

Historically, the size of a byte was not strictly defined and could vary between different computing systems. Early computers had byte sizes that ranged from as few as six to as many as 24 bits per byte, depending on what was most convenient for the hardware design or the computational needs of the era. However, as the 8-bit byte became standard with the widespread adoption of the ASCII character set and later developments in computing technology, the term "byte" has become synonymous with 8 bits in most contexts.

Despite this standardization, the term "octet" remains in use in certain technical specifications and protocols, especially in networking and telecommunications, to remove any ambiguity about the size of the data unit being discussed. For instance, in protocols like HTTP and MIME (Multipurpose Internet Mail Extensions), you'll often see references to "octet-stream" as a MIME type (application/octet-stream), which is used to represent binary data of unspecified type. This ensures clarity that the data is indeed composed of 8-bit units.

[kisdaniel]

I have a same issue, but this library worked for me earlier. I have updated some libraries with renovate-bot, it seems to me that the upgrade caused the bug.

When I start the app locally with npm command is: node_modules/@angular/cli/bin/ng.js serve --configuration es6

it work.

When I make a production build (I run it with nginx in container) I have a same issue. I use this command to make a production build:

node_modules/@angular/cli/bin/ng.js build --configuration production --aot=true --build-optimizer=true

[stephanrauh]

I bet you run into the same issue on production if you're deploying the developer version (ng b --configuration development). Did you try this already? And did you check the MIME type?

[stephanrauh]

I didn't hear from you since last week. I'm closing the ticket now.

[ziaKhan1995]

This occurred in my case in the ngx-extended-pdf-viewer library for which I added the setting on my server which is nginx.

Here is the Link to the solution.

Note: This is not a Backend server or not a frontend App issue. This is related to the server on which the App is deployed. please ask your DevOps manager to resolve this issue.

[rmdorsey]

Is there a similar fix for azure? I've updated my web.config file, but I'm still not able to see the PDF when running the app on production. Seeing this in the console.

I've added this to my web.config file:

I've added this to angular.json: