How to disable logs with a matcher?

francislavoie · August 18, 2022, 11:05pm

Yes. It’s necessary to perform config reloads, because those are done via the API. The caddy reload command actually just does an HTTP request to the API to push the new config.

I strongly recommend keeping it on. Otherwise, you have to restart the whole container to change the config, which causes downtime. You can do zero-downtime config reloads with docker-compose exec -w /etc/caddy caddy caddy reload; sets the working directory to /etc/caddy so that the Caddyfile is “right there”, then executes a command in the caddy container, with the command being caddy reload.

It’s currently not possible, but it is in the works.

github.com/caddyserver/caddy

caddyhttp: Implement `skip_log` handler

caddyserver:master ← caddyserver:skip-log-handler

opened 04:56AM - 09 Apr 22 UTC

francislavoie

+195 -116

Closes #4689 Introduces a new `skip_log` HTTP handler, which takes a matcher.… If the request matches, it will be marked to skip log emission. This is implemented by writing to a boolean flag set in the `Vars` map when the handler matches, then checking the value at the end of the request just before attempting to emit the log. Caddyfile syntax: ``` skip_log <matcher> ``` Note that the matcher is _not_ optional, in this case it is required. At the code level, this directive is registered as a non-handler directive, because `RegisterHandlerDirective` will eat the matcher tokens to put it on the route. The `skip_log` directive can be used multiple times, and the first matching one will set the skip log flag. No matcher short circuiting happens in this case when using the Caddyfile, because I didn't implement logic for merging multiple `skip_log` handlers. Technically that could be done, but it's probably not worth the effort, it would only be a super mild performance benefit for probably a lot more code. I set the handler order for `skip_log` to be right near the top, alongside the other `vars`-ish handlers. Having it early is probably ideal because I think it makes most sense to run the matchers on an unmodified request (before any `rewrite` etc). When configuring with JSON, multiple matcher sets can be configured on the one handler, which gives a very slight performance advantage if `OR` conditions are needed for matching.

The log directive enables access logs. By default, access logs are not enabled (because it can be quite noisy).

The log global option (at the top) configures logs globally (all logs, including access logs, which are just one kind of logs that Caddy emits).

Typically, people want to write their access logs to one place, and the runtime logs (the rest) somewhere else.

caddy, not caddie

Named matchers can be one-liners if you’re only using one matcher:

@static_asset path_regexp static \.(webp|svg|css|js|jpg|png|gif|ico|woff|woff2)$

@hashed_asset path_regexp static \.(css|js)$

Make sure to run caddy fmt --overwrite /etc/caddy/Caddyfile to clean up your config. Since it’s in Docker, you might need to run it like this:

docker-compose exec caddy caddy fmt --overwrite /etc/caddy/Caddyfile

You’ll notice the whitespace will be much more consistent, using tabs everywhere.

You don’t need this. Removing the Server header is pointless. It is in no way harmful. It doesn’t reveal any information that couldn’t otherwise be figured out (e.g. by analyzing TLS handshake patterns etc).

Keep in mind that Caddyfile directives are sorted according to a predetermined order. Since reverse_proxy orders higher than file_server, it will always run first, before file_server does. Which means Caddy will never serve static files for you, with this config.

Instead, you should use can use either route to override the order, or you can use handle blocks to make parts mutually exclusive. I tend to recommend handle more often.

http://mtkk.localhost {
	encode gzip

	@static path_regexp static \.(webp|svg|css|js|jpg|png|gif|ico|woff|woff2)$
	handle @static {
		root * /var/www/uploads/img
		file_server
	}

	handle {
		reverse_proxy adonis_app:3333
	}
}

Also, be careful with the header directive and matchers; see this article which explains: