Reputation: 320
Here I have included the javascripts but I got mime type is not valid:
<script type="text/javascript" src="{{ asset('/dashboard/js/components.js') }}"></script>
<script type="text/javascript" src="{{ asset('/dashboard/js/custom.js') }}"></script>
<script type="text/javascript" src="{{ asset('/dashboard/vendors/slimscroll/js/jquery.slimscroll.min.js') }}"></script>
<script type="text/javascript" src="{{ asset('/dashboard/vendors/raphael/js/raphael-min.js') }}"></script>
<script type="text/javascript" src="{{ asset('/dashboard/vendors/d3/js/d3.min.js') }}"></script>
<script type="text/javascript" src="{{ asset('/dashboard/vendors/c3/js/c3.min.js') }}"></script>
And I am getting the error below:
The script from “http://localhost/Project/public/dashboard/vendors/flotchart/js/jquery.flot.pie.js” was loaded even though its MIME type (“text/html”) is not a valid JavaScript MIME type.[Learn More] home
Loading failed for the <script> with source “http://localhost/Project/public/dashboard/vendors/flotchart/js/jquery.flot.pie.js”. home:2091:1
The script from “http://localhost/Project/public/dashboard/vendors/flot.tooltip/js/jquery.flot.tooltip.min.js” was loaded even though its MIME type (“text/html”) is not a valid JavaScript MIME type.[Learn More]
What is the problem? Please help.
Upvotes: 12
Views: 51566
Reputation: 21875
This might not appear clear that some servers, particularly, CDNs have been zipping files into gzip by default. If you upload gzip (i.e. xxx.js.gz) files, then you have an error such as:
Refused to execute script from 'https://cdn.jsdelivr.net/npm/xxx.js.gz'
because its MIME type ('application/gzip') is not executable, and
strict MIME type checking is enabled.
What you need to do is to load not zipped xxx.js file and have it in your yyy.html file with a regular script tag such as this:
<script type="text/javascript" defer="defer"
src="https://cdn.jsdelivr.net/npm/xxx.js"
crossorigin="anonymous"></script>
Upvotes: 0
Reputation: 77
This might not appear with HTML + JavaScript files that are opened in the browser from the local file system (per the URL). However, if the HTML is opened from a remote origin (including localhost), the browser will send a HTTP GET
request to retrieve this referenced resource. The response will include a number of HTTP headers as supplied by the server, which usually includes the Content-Type
header too. This header declares the MIME type for the resource retrieved. And hence, if that's not one of the JavaScript MIME types, the browser produces the warning.
Now, the MIME type from the Content-Type
HTTP header might be a different one, but the browser likely might try nonetheless to read the response's body as JavaScript code. And this is where the error can occur, if in fact the response body can't be parsed as JavaScript code.
A typical reason for this can be that you don't get JavaScript code served from the server, but a HTML error page, which the server might be configured to send in case of HTTP response status codes 404, 403, 500 or other ones like that.
If the server can't find or resolve the requested resource on its internal lookup mechanism, or if the server is lacking permission to access the resource, it will not be able to send it back to the browser as the response.
In the 403 case (also used for the case where the server denies the client the response for lack of successful prior authentication), it could well be that the rights are 600 (rwx only for the owner) or similar, so if your user account is the owner, you can successfully open the HTML + JavaScript from the local file system (per the URL), but as the server daemon might not run under your user account (but a separate account, and/or be part of a group), with lack of the read-permission for the file for group or anybody, the server is not allowed to access the file (if that's the source for the requested resource), therefore can't reply it to the requester/client/browser, and resorts to a HTTP error code, for which a HTML error page might be configured.
To investigate the actual cause of, and solution to, the problem, you may try to open the full (absolute) URL as the browser constructs it (which is relative to the remote host origin) and see what you get as response. With a Web Inspector/Debugger console, if there's a network monitor, you can investigate the headers of the response and the body payload. These may include indications of what exactly went wrong, if not in a production environment configuration. If you have access to (are in control of) the server, you can also take a look into the server's access/error logs, if any. And investigate the server's retrieval/routing/resolving to its internal source.
Upvotes: 1
Reputation: 31
This is for Node.js users:
Use 404 middleware or any other last
app.use(function(req,res,next){
res.send('page does not exist')
})
If you use this before
app.use(express.static(path.join(__dirname,'static')))
It will throw the same error.
Upvotes: 2
Reputation: 231
I faced the same problem for Node js application. Your scripts path starting with
/dashboard/js/components.js
so basically you have to use
const app = express()
const publicDirectoryPath = path.join(__dirname, '../public/')
app.use(express.static(publicDirectoryPath))
Upvotes: 3
Reputation: 61
What worked for me: After a half day research i tried just to edit the JS file. Just put a new line (ENTER) after the first (commented) line and saved it.
It was jquery minified file with a comment on the beginning. In Firefox "Inspector / Network" the .js was displayed as 404 and MIME (text/html). The strange thing was that the other .js files in the same directory were OK. Hope that helps.
Upvotes: 5