Use Caddy's request matchers, directive ordering

[francislavoie]

I saw you're using path as a matcher inside of the filter plugin. This isn't necessary, because you can already use Caddy's built-in request matchers for this.

When you register your Caddyfile directive with RegisterHandlerDirective, it allows a matcher token to be the first argument to your directive, like most other Caddyfile directives. This means you can do this:

filter /foo/* {
	...
}

If you want to use regexp patterns, then you'd do this:

@pattern {
	path_regexp ^/(foo|bar).*
}
filter @pattern {
	...
}

I would've suggested also getting rid of content_type but I think that looks at the response headers which isn't something you can do with request matching (obviously). So that one's fine to leave as-is.

Also, you should mention that users should set an order for the directive in their global options to use it, because otherwise they'll encounter an error when trying to use it (at least when outside of a route block). See https://caddyserver.com/docs/caddyfile/options, the directive ordering is here: https://caddyserver.com/docs/caddyfile/directives#directive-order

I'd recommend something like:

{
	order filter after encode
}

This will make your directive get handled just before the response is encoded (gzipped, etc) and after the response is templated.

[htfy96]

Thanks for suggestions! I've updated the doc to include the order directive (actually they exist in test file, but order filter after encode is definitely better than my order filter first.

For the Caddy's request matcher, I'll look into that this weekend.