caddyhttp.HandlerErr non-500 status logging

[jjiang-stripe]

Hello! Is there a reason why Caddy only logs handler errors that have 500-level status codes (see

caddy/modules/caddyhttp/server.go

Lines 263 to 265 in 124ba1b

	if errStatus >= 500 {
	logger.Error(errMsg, errFields...)
	}

)? I've run into this failure case before and it wasn't obvious because that error doesn't actually end up being logged because it's a 403. Are there non-500 handler errors that we don't want logged? Otherwise, that seems like it'd be useful information for debugging.

[francislavoie]

Are there non-500 handler errors that we don't want logged?

I would say yes, things like basicauth errors, because those can get very noisy, especially if some bots are making lots of attempts.

We could probably log them at the Debug level though, which would be quiet by default.

[jjiang-stripe]

hmm ok so follow-up question (sorry if this is basic! just trying to wrap my head around the semantics here): why are unauthorized responses returned as a HandlerErr? looking at

caddy/modules/caddyhttp/caddyauth/caddyauth.go

Lines 87 to 89 in 03b5deb

	if !authed {
	return caddyhttp.Error(http.StatusUnauthorized, fmt.Errorf("not authenticated"))
	}

I'm wondering what the difference is between doing something like

http.Error(w, "not authenticated", http.StatusUnauthorized)
return nil

versus returning it as a HandlerErr as it currently does.

[francislavoie]

Handler errors can be recovered from via the handle_errors directive, so you can handle them however you want, e.g. to display an error page of your choice with file_server, or re-proxy to a rewritten URL if you have an error page on your upstream you can render.

This is particularly useful for file_server itself which will emit a 404 handler error, so you can show a "page not found" 404 page. You can also do the same with basicauth and show an "Unauthorized" page instead of re-prompting for basicauth if you prefer.

[jjiang-stripe]

ahh gotcha, that makes sense, thank you for explaining!

[mholt]

(Catching up)

Yeah, so 4xx errors are client errors, not errors in the server, so we don't log those specially. But I guess it makes sense in a debug mode that logging all errors, even client ones, could be useful. Thanks for bringing up the question!