per_host metrics may contain unconfigured hosts

[gucci-on-fleek]

Fixes caddyserver/caddy#7055.

How to reproduce:

$ curl --insecure --resolve arbitrary.example.com:443:<your-server-IP> https://arbitrary.example.com/

[mholt]

This sounds terrible tbh 😆 Is this something we can fix? Or is it just a risk of enabling per-host metrics? (Which we hesitated to implement for a long time because of this problem, among some other technical problems too.)

[francislavoie]

@mholt well, caddyhttp handler writes the empty 200 responses etc on the HTTP server for unknown domains, so metrics handlers pick that up since it wraps all handlers.

[gucci-on-fleek]

@francislavoie

caddyhttp handler writes the empty 200 responses etc on the HTTP server for unknown domains

Is that behaviour intentional? The commits introducing that behaviour

• caddyserver/caddy@4a3a418

• caddyserver/caddy@7b0962b

don't seem to give any reason for this, and this doesn't appear to be documented anywhere

• (repo:caddyserver/website OR (repo:caddyserver/caddy AND path:modules/caddyhttp)) /\b200\b/

And returning 200 OK for an unhandled request doesn't quite seem right to me; any of 421 Misdirected Request, 404 Not Found, or 500 Internal Server Error seem like better choices, or maybe even TCP RST if you're feeling particularly unfriendly.

This was also discussed in caddyserver/caddy#5729, caddyserver/caddy#4026, and caddyserver/caddy#4173, but even after reading those, I still find this behaviour kinda weird. But without knowing the architecture of the metrics code, if unhandled responses always returned 421, would that make it easier to ignore unconfigured hosts (since you could filter out any 421 responses)?