HTTPS is working but HTTP is not loading

[icheered (Tjeerd Bakker)]

1. Caddy version: v2.5.0 h1:eRHzZ4l3X6Ag3kUt8nj5IxATprhqKq/wToP7OHlXWA0=

2. How I installed, and run Caddy:

docker-compose

a. System environment: Debian

Docker version 20.10.5+dfsg1, build 55c4c88
docker-compose version 1.25.0
Linux version: 5.10.0-17-amd64

b. Command:

docker-compose up caddy

c. Service/unit/compose file:

  caddy:
    image: caddy:2.5.0-alpine
    container_name: caddy
    restart: always
    ports:
      - 80:80
      - 443:443
      - 2019:2019
    volumes:
      - ./caddy-data:/data
      - ./Caddyfile:/etc/caddy/Caddyfile
      - /home/<user>/web:/var/www

d. My complete Caddy config:

icheered.nl www.icheered.nl {
  root * /var/www/ICheeredWebsite
  file_server
}

3. The problem I’m having:

https://icheered.nl works fine
http://icheered.nl is not loading

It seems that the HTTP request is not being redirected to the HTTPS version. It took a very long time for me to discover this issue because I only checked “icheered.nl” which automatically redirected to the https version, and the chrome browser on my phone redirects manually enetered http links to the https version automatically before making the request.

4. Error messages and/or full log output:

These are the logs from the docker container that is running caddy.

{"level":"info","ts":1675590145.8682392,"msg":"using provided configuration","config_file":"/etc/caddy/Caddyfile","config_adapter":"caddyfile"}
{"level":"warn","ts":1675590145.868944,"msg":"Caddyfile input is not formatted; run the 'caddy fmt' command to fix inconsistencies","adapter":"caddyfile","file":"/etc/caddy/Caddyfile","line":2}
{"level":"info","ts":1675590145.869519,"logger":"admin","msg":"admin endpoint started","address":"tcp/localhost:2019","enforce_origin":false,"origins":["//127.0.0.1:2019","//localhost:2019","//[::1]:2019"]}
{"level":"info","ts":1675590145.8696437,"logger":"http","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}
{"level":"info","ts":1675590145.8696597,"logger":"http","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv0"}
{"level":"info","ts":1675590145.869693,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0xc000438a80"}
{"level":"info","ts":1675590145.8699696,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["icheered.nl","www.icheered.nl"]}
{"level":"info","ts":1675590145.869972,"logger":"tls","msg":"cleaning storage unit","description":"FileStorage:/data/caddy"}
{"level":"info","ts":1675590145.8711853,"msg":"autosaved config (load with --resume flag)","file":"/config/caddy/autosave.json"}
{"level":"info","ts":1675590145.8712063,"msg":"serving initial configuration"}
{"level":"info","ts":1675590145.8749053,"logger":"tls","msg":"finished cleaning storage units"}

5. What I already tried:

I tried the following additions to my Caddyfile:

# Force redirect http to https
http://icheered.nl {  
    redir https://icheered.nl{uri}
}

# Redirect everything from port 80 to https
*:80 {
    redir https://{domain}{uri}
}

I checked my router’s port-forwarding and port 80 traffic is forwarded correctly to the server.

6. Links to relevant resources:

(The solution didn’t work for me)

Http to https redirect not functioning properly

For those viewing this thread. Here is the solution. In a private back and forth between Matt and myself he was able to point out my mistake. In the older version of Caddy I had been using earlier this year v0.8.3 the following would work just fine: # Redirect HTTP requests to HTTPS http://domain.com { redir https://domain.com{uri} 301 } However, my guess is that some of the ambiguity of the above statement resulted in some tweaks in the newer version, which prevents the redir line fro…

Redirect HTTP to HTTPS

v2.3.0 h1:fnrqJLa3G5vfxcxmOH/+kJOcunPLhSBnjgIvjXV/QTA= Just a little info on how we want to use Caddy. We make devices. The endpoint of all devices is a “3”. In the middle may be a “2” and a starting point is the “1”. The “1” may be connected to multiple "2"s which in turn are connected to multiple "3"s or an “1” could be connected directly to several "3"s. The “1” and “2” software was written by me. They handle dynamic protocols and path (for NAT). The “3” is legacy software and is much hard…

[emilylange]

@icheered

I checked my router’s port-forwarding and port 80 traffic is forwarded correctly to the server.

Your ISP might block it, though. Consider asking them if that’s the case.
You could also test localhost using the following command from the server that’s running Caddy:
curl -I --connect-to icheered.nl:80:127.0.0.1:80 http://icheered.nl

@icheered

1. Caddy version: v2.5.0 h1:eRHzZ4l3X6Ag3kUt8nj5IxATprhqKq/wToP7OHlXWA0=

That’s very old. Please update to the latest release, which is currently v2.6.2

Also, remove - 2019:2019 and add - 443:443/udp for http/3 instead

@icheered

      - 80:80
      - 443:443
      - 2019:2019

[icheered (Tjeerd Bakker)]

Thanks for your response. I updated the version:

v2.6.2 h1:wKoFIxpmOJLGl3QXoo6PNbYvGW4xLEgo32GPBEjWL8o=

And adjusted the port definitions to your suggestion.

When I try running the command you supplied to test locally, I’m not sure what to make of it but it seems that it can’t find the HTTP location. I ran it once with HTTP and once with HTTPS to check the difference:

 ✘ user@host  ~/services  curl -I --connect-to icheered.nl:80:127.0.0.1:80 http://icheered.nl
HTTP/1.1 302 Found
Location: https:///
Server: Caddy
Date: Mon, 06 Feb 2023 09:58:57 GMT

 user@host  ~/services  curl -I --connect-to icheered.nl:80:127.0.0.1:80 https://icheered.nl
HTTP/2 200 
accept-ranges: bytes
alt-svc: h3=":443"; ma=2592000
content-type: text/html; charset=utf-8
etag: "rd0bqn1h5"
last-modified: Sun, 05 Jun 2022 13:49:35 GMT
server: Caddy
content-length: 1913
date: Mon, 06 Feb 2023 09:59:00 GMT

[icheered (Tjeerd Bakker)]

Well I still don’t know what the problem was, but I removed and re-created my caddy file, restarted the container, and reloaded the caddy file (docker-compose exec caddy caddy reload --config /etc/caddy/Caddyfile) and now the problem has disappeared…