Currently, Caddy’s structured logging outputs all available fields in the JSON log entries, including many that may not be relevant for a particular use case. This behavior introduces several challenges:
Increased log volume: Logging every available field - including unused or low-value ones - leads to unnecessarily large log files, consuming more disk space and potentially increasing storage costs.
Signal-to-noise ratio: The excess of irrelevant fields makes it harder to extract meaningful insights quickly, especially in production systems where clarity and performance matter.
Security risk and stability concern: Malicious actors could inject large or numerous custom headers, causing logs to balloon in size and possibly impacting system performance or log processing pipelines.
To mitigate these issues, it would be beneficial to introduce a configuration option that defines a whitelist of log fields for JSON logging. This would give users explicit control over which fields are logged, improving efficiency, clarity, and resilience.
In general though, we recommend processing logs as a separate step in your infrastructure (unless someone wants to write a Caddy app that does it): How Logging Works — Caddy Documentation
Not quite — we’ve reviewed the transform-encoder module, but unfortunately it doesn’t meet our needs. It outputs plain strings instead of structured JSON, which forces us to manually build JSON-like strings. This is a workaround, not a proper solution. For example:
log main {
output stdout
format transform `{\"level\":\"{level}\",\"ts\":\"{ts}\",\"logger\":\"{logger}\",\"ip\":\"{request>remote_ip}\",\"user_id\":\"{user_id}\",\"request\":\"{request>method} {request>uri} {request>proto}\",\"status\":{status},\"size\":{size}}` {
unescape_strings
}
}
What’s also confusing is that Caddy already supports a field exclusion (blacklist) mechanism, which shows that the internal logging system is capable of selective field control. But there’s still no support for a whitelist, which has been requested multiple times and repeatedly declined — with no clear explanation.
Adding whitelist support would eliminate the need for custom modules and fragile formatting hacks, and would bring logging configuration in line with common operational requirements — especially when managing log volume, structure, and security.
We hope this can be reconsidered as a native feature.
I can’t reduce the limit—I need to be able to accept headers of the required size. Requests with near-maximum header sizes are typically rare. But this particular behavior of Caddy could become an attack vector. Some Caddy users may not even be aware of this vulnerability.