The filter log encoder addresses log fields by path, using > as the nesting separator (e.g. request>uri, request>headers>Authorization). The plugin's parser does not accept > inside a directive name, so any Caddyfile using the documented filter syntax is reported as a syntax error.
Minimal reproduction
example.com {
log {
format filter {
wrap console
fields {
request>uri replace /webhook/REDACTED
}
}
}
}Actual result
Two errors:
- line 6, col 5 — , CaddyTokenType.COMMENT, CaddyTokenType.EOL, CaddyTokenType.MATCHER or CaddyTokenType.RBRACE } expected, got 'request>uri'
- line 10, col 1 — , CaddyTokenType.COMMENT or CaddyTokenType.EOL expected, got '}'
The second one looks like a cascade from the first: after the failed field line the parser loses track of the enclosing block, and the closing brace of the site block ends up unexpected.
Expected result
No errors — the config above is valid. Verified with Caddy v2.11.4 (official caddy:2 Docker image):
$ caddy validate --config Caddyfile --adapter caddyfile
... adapted config to JSON ...
Valid configuration
$ caddy adapt --config Caddyfile | jq '..|.fields?|select(.)'
{"request>uri": {"filter": "replace", "value": "/webhook/REDACTED"}}Notes
- Quoting the field name ("request>uri" replace /webhook/REDACTED) produces the exact same two errors, so there is no workaround on the Caddyfile side — the nested path is the syntax.
- Replacing the field with a plain identifier (uri replace /webhook/REDACTED) parses without errors, which isolates > as the trigger.
- Because these are parser errors rather than inspections, they cannot be suppressed per-file; the only way to silence them today is to unregister the file from the Caddyfile file type.
- The same field-path syntax appears throughout the log directive documentation: https://caddyserver.com/docs/caddyfile/directives/log (the canonical example being request>headers>Authorization delete).
Environment
- Plugin: Caddyfile support 2026.2.0 (com.github.xepozz.caddy)
- IDE: WebStorm 2026.2
- OS: Windows 11
- Caddy: v2.11.4
The filter log encoder addresses log fields by path, using > as the nesting separator (e.g. request>uri, request>headers>Authorization). The plugin's parser does not accept > inside a directive name, so any Caddyfile using the documented filter syntax is reported as a syntax error.
Minimal reproduction
Actual result
Two errors:
The second one looks like a cascade from the first: after the failed field line the parser loses track of the enclosing block, and the closing brace of the site block ends up unexpected.
Expected result
No errors — the config above is valid. Verified with Caddy v2.11.4 (official caddy:2 Docker image):
Notes
Environment