That did it. Thanks for taking the time to reply. I wouldn’t have arrived at that combination in a million years at least by looking at the docs. Can I suggest adding this particular example to the docs?
Although part of that is a bit outdated. Next week, matchers are changing a bit (improving).
Basically, a matcher token makes that directive selective to only requests which match the matcher.
A * is a wildcard matcher. It’s implicit and can usually be omitted entirely, except that the next argument also looks like a path matcher. A path matcher starts with / and is the most common kind of matcher, so it’s a special case in that it can be defined inline. Other matchers can take the form @matcher_name which are defined in their own block. This is helpful when matching on some property of the request other than the path.
In Caddy 2, you sure can. You can set a different root depending on the kind of request you get (like its path, or anything else about it). It still means “root of the site” or “file root” so it’s still in harmony with the word.
You can’t arbitrarily nest directives inside other ones, unless the directive is specially designed to have other directives within it.
Yeah, we’re not nginx … contexts aren’t as much of a thing in the Caddyfile. The Caddyfile is much simpler, but also about as powerful.
Thanks. Yeah, the Caddyfile needed some polish and now it’s getting it, so it’ll be as easy to use as in v1 but even more powerful and flexible. Tricky to strike that balance. I hope you like the improvements.