Recently, while deploying a personal project, I encountered something I thought I understood.
I originally just wanted to add HTTPS to the frontend to allow the camera permission to pop up normally, but after making the change, all requests from the frontend page failed, and the console was filled with errors. Eventually, I discovered that I had inadvertently created a pitfall—an HTTPS page was secretly requesting an HTTP interface, which was ruthlessly blocked by the browser.
The process of falling into this pit was not complicated, but the underlying knowledge points are worth discussing. Thus, this record was created.
🧩 Cause of the Problem
My project is a web application with a separated frontend and backend, developed using Expo. During local development and debugging, everything worked fine. However, after deploying the project online, I suddenly found:
When accessed from a mobile browser, the camera permission request does not pop up at all!
After some investigation, I consulted some materials and noticed this point:
For security reasons, browsers only allow requests for sensitive permissions like camera and microphone within HTTPS pages.
So, I quickly configured an HTTPS certificate for the frontend page; the specific process can be referenced in my previous blog post👇:
https://www.nxcoding.com/archives/1panel-https-auto-renew
After deployment, the camera permission finally popped up normally ✅. However, the good times didn’t last long, as a new problem immediately arose:
All interface requests on the page suddenly failed.
🚨 Console Error Messages
At first, I thought it was a cross-origin issue or a mistake in the interface address, but upon closer inspection, I found it was neither.
Guided by a large model, I opened the browser console and saw the following error:
Mixed Content: The page at 'https://xxxx.xxxxxxx.com/' was loaded over HTTPS,
but requested an insecure XMLHttpRequest endpoint 'http://xxxxxxxxxxxxx.xxxxxxxx.com/xxx'.
This request has been blocked; the content must be served over HTTPS.💥 A wake-up call!
🎯 Cause of the Problem
In short:
The frontend page is HTTPS, but the backend interface is still HTTP.
This caused a typical “Mixed Content” issue. The browser directly blocked these requests, not even giving them a chance.
Among them, requests like XHR are considered “Active Mixed Content” and will be directly intercepted by modern browsers, even if the server has responded, they cannot return to the frontend at all.
🔧 Solution Approach
Once the problem was identified, the solution was actually quite simple:
- 1. Use 1Panel tool to configure HTTPS for the backend service as well;
- 2. Replace all interface addresses in the frontend code with
<span>https://</span>protocol.
✅ After completing these two steps, the interfaces finally returned to normal, and everything ran smoothly.
📚 Technical Background Supplement: Why Can’t HTTP and HTTPS Be Mixed?
Many developers, like me, will be very confused when encountering this problem for the first time: why do HTTP interfaces that can be accessed fail when placed in an HTTPS page? Here’s a brief background knowledge supplement.
✅ What is Mixed Content?
Mixed Content refers to:
Loading insecure HTTP resources within an HTTPS page.
It can be categorized by type as follows:
| Type | Example | Browser Default Behavior |
| Active Content | JS, XHR, iframe | Directly Blocked |
| Passive Content | Images, audio | Sometimes warned, sometimes allowed |
❌ Why is it Unsafe?
- 1. Risk of Man-in-the-Middle Attacks (MITM)HTTP request content can be intercepted and tampered with, and attackers may insert malicious code.
- 2. Destruction of Encryption Link IntegrityThe HTTPS page, which should be fully encrypted, creates a “break” by loading HTTP content.
- 3. Misleading User Security PerceptionUsers see the lock icon and think the page is secure, but it has actually embedded insecure content.
✅ Summary
- • To solve the issue of the camera permission not popping up, I switched the frontend to HTTPS;
- • I did not synchronize the modification of the interface protocol, which led to the browser blocking all requests;
- • After configuring HTTPS for the backend as well and unifying the protocols for both frontend and backend, the problem was successfully resolved;
- • Throughout the process, I gained a deeper understanding of the “mixed content” issue and its security mechanisms;
🤔 Reflection
Actually, I had heard about the issue of “HTTPS pages not being able to request HTTP interfaces” before, and I had seen many examples of man-in-the-middle attacks while watching videos related to browser security.
But to be honest, at that time, I only “knew” this knowledge point,it was far less vivid than this deployment pitfall.
🔍 This experience made me realize:
Knowledge related to security is only truly ingrained in your mind after you have personally encountered pitfalls and debugged issues.
It also reminds me:
Deployment is not just about getting the functionality to run; it is also essential to pay attention to protocols, permissions, environments, browser behaviors, and other comprehensive factors.