Handle the default case of map directive differently

[pLoP]

1. The problem I’m having:

I want to have different behavior when a default match happens in the map directive, and I can’t seem to get it to work.

For any other sub-subdomain except for the listed ones, I should get a 404 response, but I’m currently getting a 502, and from the logs it looks like caddy is still trying to reverse proxy for those cases. I don’t quite understand why it’s happening.

2. Error messages and/or full log output:

"logger":"http.log.error","msg":"dial tcp: lookup dummy on 8.8.8.8:53: no such host"

when trying to access an “invalid” route.

3. Caddy version:

v2.8.4 h1:q3pe0wpBj1OcHFZ3n/1nl4V4bxBrYoSoab7rL9BMYNk=

4. How I installed and ran Caddy:

a. System environment:

AlmaLinux 9.4 x86_64

b. Command:

systemctl enable --now caddy

c. Service/unit/compose file:

Irrelevant.

d. My complete Caddy config:

vps6.dedyn.io, *.vps6.dedyn.io {
        tls {
                dns desec {
                        token "<token>"
                }
        }

        map {labels.3} {backend} {prt} {
                files localhost 5091
                jellyfin server 80
                music server 80
                default dummy 0
        }

    @invalid `{prt} == 0`
    handle @invalid {
        respond 404
    }

    reverse_proxy {backend}:{prt}
}

5. Links to relevant resources:

I was trying to use this solution.

[francislavoie]

I think you have to do == "0"

But it’s weird because it’s meant to take numeric map outputs as numbers, not strings. Hmm.

[francislavoie]

Oh I see the problem, weird. We do the type conversion for regular map cases, but for the default case we store it as []string in the JSON config. Whoops.

[pLoP]

So, for now I need to convert it to string, yes? I hope this will be fixed in the future?

[francislavoie]

Yeah just do a string comparison.

I haven’t looked into whether we can fix it or not, it might have knock-on effects.

[francislavoie]

Oh yeah, the other option is you can use the vars matcher instead of an expression matcher

	@invalid vars {prt} 0
	handle @invalid {
		respond 404
	}

[pLoP]

Great, thanks for the help. I think the expression matcher makes more semantic sense for me, and I use it in other parts of my Caddyfile as well. So I’ll just stick to that.