I just wrote a new article for our wiki: https://caddy.community/t/why-caddy-emits-empty-200-ok-responses-by-default/17634

It explains why Caddy does what it does for "no-op" requests; that is, why Caddy emits 200 OK even when it wasn't configured to do anything.

This issue is here to discuss one more time whether that behavior could be improved upon. I recently heard a use case from a contact within a company exploring Caddy that the 200 behavior was surprising and made it difficult to troubleshoot whether the request was being handled partially or not at all (i.e. what routes was it taking that it ended up as a no-op?). Misconfigured routes -- maybe matchers that don't match what is expected -- or missing handlers can cause confusion.

I'd be open to discussing a non-standard 2xx status code to make it more obvious that the server is working, but lacks configuration to invoke an application or originate content. For example, 290 NOP? I dunno.

I don't love this because clients won't know what to do with it. Some clients just look at the first digit to get the gist of what happened. Others expect a specific 20x. Who knows what this would break.

For reasons stated in the wiki article above, I'm not inclined to change this behavior.

Personally, I think a better solution than changing the status code is to provide better config debugging tools.

• Config assertions: given a test corpus, ensure tests pass before applying config. Idea: configuration assertions #4537
• Request tracing in the debug-level logs: emit a log when matchers and handlers are evaluated.

The latter might not be too hard to get something simple working, so I'll push a branch later with my tinkering.

Feedback welcome in the meantime.

Prior work/discussion in:

• Add debug log if a request was not explicitly matched/handled #3445 and caddyhttp: Add debug log when the response wasn't written to #3446
• Consider improvements to default route handling when no server or handler match #3879
• Caddy responds 200 for unmatched routes #4026
• v2: Any requested document returns always 0 bytes #3226