Mixed content frames

[nathangemmill]

1. Caddy version (caddy version):

v2.4.3

2. How I run Caddy:

a. System environment:

Docker container.

d. My complete Caddyfile or JSON config:

website.com {
        reverse_proxy /* 172.17.0.2:2368
}
mysite.website.com {
        reverse_proxy /* 172.17.0.4:9000
}

3. The problem I’m having:

Certain frames on the site I’m serving will not load due to mixed content warnings which I can see in the browser developer console. See error message below.

4. Error messages and/or full log output:

Mixed Content: The page at ‘https://website.com/ghost/#/site’ was loaded over HTTPS, but requested an insecure frame ‘http://website.com/?v=1631100936328’. This request has been blocked; the content must be served over HTTPS.

5. What I already tried:

I’ve tried adding the below but did not make any difference.

proxy_header Host {host}
proxy_header X-Forwarded-Proto {scheme}
proxy_header X-Real-IP {remote}

6. Links to relevant resources:

Caddy Server | Reverse Proxy | Automatic TLS: Wordpress CSS causing page to be broken post load

1. My Caddy version (caddy -version): v2.0.0-beta11 2. How I run Caddy: ./caddy run --config myConfig.json a. System environment: OS, relevant versions, systemd? docker? etc. Distributor ID: Ubuntu Description: Ubuntu 16.04.5 LTS Release: 16.04 Codename: xenial d. My complete Caddyfile: { "admin": { "listen": ":2019" }, "apps": { "http": { "servers": { "reverse_proxy_master": { "listen": ["0.0.0.0:443"], "@id" : "reverse_…

Anyone have any luck with mixed-content / forcing HTTPS on proxy requests?

Trying to tie together Caddy with an Apache/AJP backend to forward requests. That seems to work fine: but the backend application is putting out occasional “http” content requests; they’re not all getting converted to https. # Make sure HTTP goes to HTTPS redir 301 { if {>X-Forwarded-Proto} is http / https://{host}{uri} } # INTERNAL Proxy: pass to local Apache/AJP router rewrite /external /internal proxy /internal http://localhost:8080 { except {dir}/robots.txt transparent }

[jok (Jochen)]

Do you use Ghost?
If yes, do you have the “url” configured?

Using docker-compose i have defined this as an environment variable, you probably have to set

url: "https://website.com/ghost/"

(not sure about the /ghost/ part, as i use a subdomain for it)
see Configuration - Adapt your publication to suit your needs

[francislavoie]

@nathangemmill

reverse_proxy /* 172.17.0.2:2368

Remove the /*, this is redundant and very slightly less efficient than using * or omitting the matcher altogether (which is the same as *), because it makes Caddy do a path comparison on every request, which is unnecessary (only nanoseconds of difference per request, but still).

        reverse_proxy 172.17.0.2:2368

That said, @jok is probably right, this is most likely a configuration problem on your upstream app. Caddy sets the X-Forwarded-Proto automatically, but if the upstream app doesn’t use it to determine what scheme to use for its URLs, then there’s nothing else you can really do in Caddy to solve it.

reverse_proxy (Caddyfile directive) - Caddy Documentation

[nathangemmill]

Yeah, I use ghost! I have indeed configured the url variable but I configured it as http://website.com in order to use allow me to reverse proxy and secure the site using caddy. I’m concerned that if I change the url variable to https://website.com instead, it will cause issues with caddy not being able to secure the site due to the site already using https://. Do you think this would be an issue?

[nathangemmill]

Bugger, alright I will try deploy another container as you’ve suggest but I’m concerned it might not work with Caddy as it’ll think it’s already protected with https. Fingers crossed!

[nathangemmill]

Hey @jok, I have confirmed that redeploying my container with https://website.com instead of http://website.com does not cause any issues and it has fixed my mixed content frame previews! Thank you very much for the advice!