Mixed Content Error on Mixed Hosts

[Redford_Kobayashi]

Simplified, I have testDir/index.html which I’m serving through Caddy in a dockerised version. I also have a backend container written in Node serving JSON through HTTP.

Inside index.html when I attempt to make a API call to the backend, the browser shows:

index-CTeuxYjg.js:49 Mixed Content: The page at 'https://localhost/' was loaded over HTTPS, but requested an insecure resource 'http://backend:3000/api/people'. This request has been blocked; the content must be served over HTTPS.

It’s a fetch request like:

console.log("Will do some crap");
      fetch('http://domain-backend:3000/api/people')
        .then(response => response.json())
        .then(data => console.log(data))
        .catch(error => console.error('Error fetching data:', error));

I’ve tried many variations for this but still the same error.
The dockerfile for the caddy container is this:

FROM node:20-alpine AS build

WORKDIR /frontend

COPY package*.json .

RUN npm install

COPY . .

RUN npm run build

FROM caddy:2.7.6-alpine

EXPOSE 80

EXPOSE 443

COPY --from=build /frontend/dist /dist

COPY --from=build /frontend/testDir /testDir

CMD ["caddy", "run", "--config", "/etc/caddy/Caddyfile"]

And the caddyfile is:

domain.pro, www.domain.pro, localhost {
  root * /dist
  file_server
}

What could possibly be causing this issue? I scoured the Web and I can’t find anything on this.

[timelordx]

Why do you call it “Caddy shenanigans” when it has nothing to do with Caddy and everything to do with mixing HTTPS and HTTP content in a browser?

You’re accessing an HTTPS site (https://localhost/), but your code in the browser is trying to call an HTTP resource (http://domain-backend:3000/api/people). The error message you’re seeing is just your browser blocking mixed content - it’s not allowed.

fetch is simply blockable content.

[Mohammed90 (Mohammed Al Sahaf)]

For the sake of other users who use the forum for help, please use descriptive title.

[Redford_Kobayashi]

Yeah, sorry it was a bad title. Likely asking for help here isn’t the best choice since it’s not related to Caddy. Any ideas how this can be solved?

I read about others using similar setup caddy as reverse proxy and containers behind the scene making API requests.

@Mohammed90 Yeah sorry, my bad.

[Redford_Kobayashi]

Here’s the thing, when I run it outside of a Docker container like a regular static html file and I serve it and then I relay the api requests to the node process, it doesn’t complain about that.

(no docker for any of the containers)

Here’s the Caddyfile for that, easy peasy lemon squeeze.

localhost {
	root * ./frontend
	file_server
	reverse_proxy /api/* localhost:3000
}

So how come HTTP and HTTPS mixed content isn’t the issue like this?

[timelordx]

If your browser loads the content of the page via HTTPS, then your fetch must be against HTTPS as well.

console.log("Will do some crap");
      fetch('https://YOUR_API_SITE')
        .then(response => response.json())
        .then(data => console.log(data))
        .catch(error => console.error('Error fetching data:', error));

[timelordx]

@Redford_Kobayashi

no docker for any of the containers

It doesn’t matter whether you’re using containers or not - your browser won’t load non-secure (HTTP) content on a secure (HTTPS) page. That’s just how it works.

If you load the page from an HTTP site or a local HTML file, the browser will allow connections to an HTTP site. When loading from a local HTML file, behaviour can vary slightly depending on the browser and security settings. Some browsers treat file:// URLs differently and may block mixed content in certain cases.

You can read more about it on the page I linked in my previous comment:

Mixed content - Security on the web | MDN

[timelordx]

@Redford_Kobayashi

With all due respect, you should stop replying in this topic. You are a newbie. I already told you that without Docker containers it’s fine even though my Node backend serves HTTP content and in that case doesn’t complain of mixed content.

LOL, really? A newbie? I manage F5 BIG-IP load balancers at work and deal with HTTP/S stuff pretty much daily. You don’t understand how HTTPS vs. HTTP content works (or doesn’t) on the same page, yet you’re calling me a newbie?

[Redford_Kobayashi]

And that’s not how it works, since I already told you that it WORKS when I don’t use Docker containers even though the NODE backend doesn’t use HTTPS. I am not a Caddy expert but this should obviously work and it does (once Docker containers aren’t used).

If you still don’t believe me, I will share the code with you.

[timelordx]

It works because you’re loading the page from HTTP and then you’re making a call to HTTP. That’s NOT a mixed content!

[Redford_Kobayashi]

It says connection is secure, that means it’s https, no?

[Mohammed90 (Mohammed Al Sahaf)]

What @timelordx says is correct. The API backend here is not Caddy

@Redford_Kobayashi

fetch('http://domain-backend:3000/api/people')

rather your app that isn’t proxied by Caddy. You should proxy to your app via Caddy so everything is over HTTPS. You already know that it works as evident by your comment here:

Mixed Content Error on Mixed Hosts

Here’s the thing, when I run it outside of a Docker container like a regular static html file and I serve it and then I relay the api requests to the node process, it doesn’t complain about that. (no docker for any of the containers) Here’s the Caddyfile for that, easy peasy lemon squeeze. localhost { root * ./frontend file_server reverse_proxy /api/* localhost:3000 } So how come HTTP and HTTPS mixed content isn’t the issue like this?

This is how it should be, not how you’re doing it on the first post.

You need to get your facts straight because the reported observations contradict themselves. Here you say:

@Redford_Kobayashi

I already told you that it WORKS

@Redford_Kobayashi

the NODE backend doesn’t use HTTPS

Then you say:

@Redford_Kobayashi

It says connection is secure, that means it’s https

Either it is HTTPS or not HTTPS. It cannot be both. Your complaint of mixed content is because you’re mixing HTTP (no S) in your API by calling you node backend directly while the page itself is served on HTTPS via Caddy. Put everything behind Caddy.

[timelordx]

Depending on your setup the browser may cache old content. Try clearing your browser’s cache or using incognito mode to make sure you’re not loading the previous content from the browser’s cache.

[Redford_Kobayashi]

@Mohammed90

rather your app that isn’t proxied by Caddy. You should proxy to your app via Caddy so everything is over HTTPS. You already know that it works as evident by your comment here:

So this Caddyfile: (wihout docker containers)

localhost {
	root * ./frontend
	file_server
	reverse_proxy /api/* localhost:3000
}

and this one: (with docker containers)

domain.pro, www.domain.pro, localhost {
  root * /testDir
  file_server
  reverse_proxy /api/* domain-backend:3000
}

Are different in that in the first one, caddy is proxying correctly requests to node process running on 3000, but in the second just because it’s a docker container it magically fails.

On the frontend I tried:

fetch('https://localhost/api/people')
        .then(response => response.json())
        .then(data => console.log(data))
        .catch(error => console.error('Error fetching data:', error));

and it again complains for mixed content. Almost equivalent Caddyfiles, one is a process the other is a docker container but somehow in the second one according to you Caddy fails to proxy the requests.

[Mohammed90 (Mohammed Al Sahaf)]

This statement is not an error message nor a log line

@Redford_Kobayashi

it magically fails

Tell us what you’re seeing in full. What’s in the logs? What’s on the browser network tab and console?

[Redford_Kobayashi]

And logs:

2025-03-28 00:25:40 {"level":"info","ts":1743117940.4105997,"msg":"using provided configuration","config_file":"/etc/caddy/Caddyfile","config_adapter":""}
2025-03-28 00:25:40 {"level":"warn","ts":1743117940.4115343,"msg":"Caddyfile input is not formatted; run 'caddy fmt --overwrite' to fix inconsistencies","adapter":"caddyfile","file":"/etc/caddy/Caddyfile","line":2}
2025-03-28 00:25:40 {"level":"info","ts":1743117940.4124436,"logger":"admin","msg":"admin endpoint started","address":"localhost:2019","enforce_origin":false,"origins":["//127.0.0.1:2019","//localhost:2019","//[::1]:2019"]}
2025-03-28 00:25:40 {"level":"info","ts":1743117940.4128613,"logger":"http.auto_https","msg":"server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS","server_name":"srv0","https_port":443}
2025-03-28 00:25:40 {"level":"info","ts":1743117940.412963,"logger":"http.auto_https","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv0"}
2025-03-28 00:25:40 {"level":"info","ts":1743117940.4150307,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0x400012fc00"}
2025-03-28 00:25:40 {"level":"warn","ts":1743117940.4263406,"logger":"tls","msg":"storage cleaning happened too recently; skipping for now","storage":"FileStorage:/data/caddy","instance":"c9b1424a-c17b-4d6c-8c5a-462ba3197381","try_again":1743204340.426337,"try_again_in":86399.999999166}
2025-03-28 00:25:40 {"level":"info","ts":1743117940.4288456,"logger":"tls","msg":"finished cleaning storage units"}
2025-03-28 00:25:40 {"level":"warn","ts":1743117940.4510117,"logger":"pki.ca.local","msg":"installing root certificate (you might be prompted for password)","path":"storage:pki/authorities/local/root.crt"}
2025-03-28 00:25:40 {"level":"info","ts":1743117940.451458,"msg":"warning: \"certutil\" is not available, install \"certutil\" with \"apt install libnss3-tools\" or \"yum install nss-tools\" and try again"}
2025-03-28 00:25:40 {"level":"info","ts":1743117940.4514732,"msg":"define JAVA_HOME environment variable to use the Java trust"}
2025-03-28 00:25:40 {"level":"info","ts":1743117940.4913414,"msg":"certificate installed properly in linux trusts"}
2025-03-28 00:25:40 {"level":"info","ts":1743117940.491778,"logger":"http","msg":"enabling HTTP/3 listener","addr":":443"}
2025-03-28 00:25:40 {"level":"info","ts":1743117940.4919198,"msg":"failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 2048 kiB, got: 416 kiB). See https://github.com/quic-go/quic-go/wiki/UDP-Buffer-Sizes for details."}
2025-03-28 00:25:40 {"level":"info","ts":1743117940.492181,"logger":"http.log","msg":"server running","name":"srv0","protocols":["h1","h2","h3"]}
2025-03-28 00:25:40 {"level":"info","ts":1743117940.4922688,"logger":"http.log","msg":"server running","name":"remaining_auto_https_redirects","protocols":["h1","h2","h3"]}
2025-03-28 00:25:40 {"level":"info","ts":1743117940.4922762,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["localhost"]}
2025-03-28 00:25:40 {"level":"warn","ts":1743117940.505524,"logger":"tls","msg":"stapling OCSP","error":"no OCSP stapling for [localhost]: no OCSP server specified in certificate","identifiers":["localhost"]}
2025-03-28 00:25:40 {"level":"info","ts":1743117940.5061018,"msg":"autosaved config (load with --resume flag)","file":"/config/caddy/autosave.json"}
2025-03-28 00:25:40 {"level":"info","ts":1743117940.5061724,"msg":"serving initial configuration"}

[Mohammed90 (Mohammed Al Sahaf)]

Something is still going to http://domain:3000/api/people, which is not Caddy and not HTTPS. Either your JS is still wrong, or, as timelordx said, somthing is cached.

[Redford_Kobayashi]

Yeah, some caching was done from docker compose, that’s it, now it works. It was crazy weird!

Thank you all. Hahaha.

For others, run:

docker compose up -d --build to rebuild to avoid some caching nonesense.