Question: module - Request matching is not internally handled for modules in http.handlers?

[z3ntl3_root]

The title is it.

Here is the source: GitHub - Z3NTL3/caddyguard: IP reputation middleware plugin for Caddy.

Everything works perfectly, unless the request matcher. Something like this doesnt work:

{
	order guard before respond
}

:2000 {
	guard /api {
		# rotating_proxy 1.1.1.1
		timeout 3s
		ip_headers cf-connecting-ip {
			more1
			more2
			more3
		}
		#pass_thru 
	}
	respond "ok"
}

It applies to * instead of /api, I thought every directive, even custom plugin ones, had first token reserved for request matchers, no ?

Caddy docs clearly state:

In the Caddyfile, a matcher token immediately following the directive can limit that directive’s scope. The matcher token can be one of these forms:

[z3ntl3_root]

nvm found it out after looking in go ref:

should provide a valid matcher set, in my case using RegisterHandlerDirective seems more logical, because its a module in namespace http.handlers

func parseCaddyfile(h httpcaddyfile.Helper) ([]httpcaddyfile.ConfigValue, error) {
	var g Guard
	err := (&g).UnmarshalCaddyfile(h.Dispenser)

	return h.NewRoute(caddy.ModuleMap{}, &g), err
}

feedback:

those things should be better documented in the docs, and as of for the reference, everything is split up in caddyhttpfile, caddyconfig this and that, was hard to find for me, idk how others experience it.

[matt (Matt Holt)]

I’ll try to make things more clear in the new docs. Thanks!