vue.jshttp

A module which is specified to be imported using HTTPS is sometimes blocked by browser because the browser loads it over HTTP

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.com/@jsquash/jpeg@1.4.0?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://~.com/' was loaded over HTTPS, but requested an insecure script 'http://unpkg.com/@jsquash/jpeg@1.4.0/index.js?module'. This request has been blocked; the content must be served over HTTPS.

enter image description here

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.

This 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.

Solution

  • 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.com/@jsquash/jpeg@1.4.0?module to unpkg.com/@jsquash/jpeg@1.4.0/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.