I developed a website for internal company use using Vue.

There is only one library in the project that is imported through an external CDN:

<script setup>
import { encode as encodeJPEG } from "/@jsquash/[email protected]?module";
</script>

The site has been working fine for over a year, but recently I received reports that the site wasn't displaying. When investigating, I found the following error in the console:

Mixed Content: The page at 'https://~/' was loaded over HTTPS, but requested an insecure script '/@jsquash/[email protected]/index.js?module'. This request has been blocked; the content must be served over HTTPS.

The most common solution I found when searching Stack Overflow was to add the following header:

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests" />

Since I only imported the external CDN for development convenience, I've resolved the issue by building the library and serving it as an internal resource.

However, I'm curious about why the browser attempted to download via HTTP when the project's build output (obviously) specifies importing the library via HTTPS protocol?

Below image shows the code after being built in Vue.

The error appears temporarily and disappears when refreshing the page later.

I apologize that I cannot provide a site to reproduce the error, as the site works normally most of the time.

I developed a website for internal company use using Vue.

There is only one library in the project that is imported through an external CDN:

<script setup>
import { encode as encodeJPEG } from "https://unpkg/@jsquash/[email protected]?module";
</script>

The site has been working fine for over a year, but recently I received reports that the site wasn't displaying. When investigating, I found the following error in the console:

Mixed Content: The page at 'https://~/' was loaded over HTTPS, but requested an insecure script 'http://unpkg/@jsquash/[email protected]/index.js?module'. This request has been blocked; the content must be served over HTTPS.

The most common solution I found when searching Stack Overflow was to add the following header:

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests" />

Since I only imported the external CDN for development convenience, I've resolved the issue by building the library and serving it as an internal resource.

However, I'm curious about why the browser attempted to download via HTTP when the project's build output (obviously) specifies importing the library via HTTPS protocol?

Below image shows the code after being built in Vue.

The error appears temporarily and disappears when refreshing the page later.

I apologize that I cannot provide a site to reproduce the error, as the site works normally most of the time.

• vue.js
• http

• The question needs a way to reproduce or debugging info in order to be answered. Currently this can be done only on your side. You can see what happens exactly with the request in network tab, and you can place breakpoints in call stack mentioned in the error if there is programmatic mistake. There's no such behaviour in general. It would be possible if a website (unpkg) redirects https to http. In your case at least 1 redirect happens, unpkg/@jsquash/[email protected]/index.js?module - > unpkg/@jsquash/[email protected]/index.js?module (to index.js entry point) – Estus Flask Commented yesterday
• 1 Probably this case, github/unpkg/unpkg/issues/443 . I wouldn't ever touch unpkg for prod, it's just awful and failed me many times even in dev – Estus Flask Commented yesterday
• Thank you @EstusFlask It seems to be an intermittent issue due to the external CDN configuration, so I'm going to close this question. – Donggi Kim Commented yesterday
• I don't see a procedure to just close the question without deleting it, so I'll leave it as is. Thanks again for the comment. – Donggi Kim Commented yesterday
• I'll post it as an answer then in case somebody has the same problem. Glad it helped – Estus Flask Commented yesterday

1 Answer 1

It can be seen what happens exactly with a request in network tab, and you can place breakpoints in call stack mentioned in the error if there is programmatic mistake.

There's no such behaviour in general. It would be possible if a website (unpkg) redirects https to http. Here at least one redirect happens for index.js entry point, unpkg/@jsquash/[email protected]?module to unpkg/@jsquash/[email protected]/index.js?module. Due to the volatile nature of the problem it can be assumed this is the case. There is a known recent issue with unpkg.