Skip to content

Use Caddy's request matchers, directive ordering #2

@francislavoie

Description

@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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions