Caddy tries to listen to port 80 even though not specific in POSTed config (Admin API)

1. Caddy version (caddy version):

v2.2.0 h1:sMUFqTbVIRlmA8NkFnNt9l7s0e+0gw+7GPIrhty905A=

2. How I run Caddy:

$ caddy run

a. System environment:

Arch Linux kernel 5.8.14-arch1-1

b. Command:

$ curl -X POST -H "Content-Type: application/json" -d '{"apps":{"http":{"servers":{"my-id":{"listen":[":2015"],"routes":[{"match":[{"host":["localhost:2015"]}],"handle":[{"handler":"static_response","body":"hello"}]}]}}}}}' http://localhost:2019/config/

{"error":"loading new config: http app module: start: tcp: listening on :80: listen tcp :80: bind: permission denied"}
Formatted JSON body from above request
{
  "apps": {
    "http": {
      "servers": {
        "my-id": {
          "listen": [
            ":2015"
          ],
          "routes": [
            {
              "match": [
                {
                  "host": [
                    "localhost:2015"
                  ]
                }
              ],
              "handle": [
                {
                  "handler": "static_response",
                  "body": "hello"
                }
              ]
            }
          ]
        }
      }
    }
  }
}

3. The problem I’m having:

As far as I can tell, this request should be successful and as a result, Caddy should start listening to localhost:2015 and return “hello” when doing a GET request.

4. Error messages and/or full log output:

ERROR   admin.api       request error   {"error": "loading new config: http app module: start: tcp: listening on :80: listen tcp :80: bind: permission denied", "status_code": 500}

5. What I already tried:

Digging through source + docs + searched the forum for similar problems. Guess there are some defaults that I’m not finding, or I’m using the wrong syntax for the “Host” but not finding the right places where this is defined.

Found my mistakes (plural). First, host is without the port (above I had “localhost:2015” instead of just “localhost”). Secondly, found that it’s the automatic SSL that starts to listen to both :80 and :443 to do the challenge, makes sense. Disabling automatic SSL (With :automatic_https {:disable true} set on the server) makes the root of the problem go away.

Thanks for the rubber ducking :slight_smile:

2 Likes