Why was path matching made exact?

In the upgrading to Caddy v2 documentation, it explains that the path matcher has been made exact, rather than prefix like in v1.

handle /foo* {
  respond /foo/bar "you are at /foo/bar"
  respond /foo "you are at /foo"
}

At first glance this seems unintuitive to me — if you’ve already matched /foo in handle /foo* why do you need to match it again in respond /foo/bar "you are at /foo/bar"? I have unsuccessfully tried searching through issues and PRs as I’m interested to find the context behind this, would someone be able to point me in the right direction?

Because it was otherwise impossible to match on just / for example to only handle requests to the root of your site. It’s as simple as that. Caddy v1’s design made it hard or impossible to do all kinds of simple config tasks.

Speaking specifically to your usecase, I think Strip path for reverse proxied requests · Issue #3266 · caddyserver/caddy · GitHub will help here with handle_path, because it’ll strip the matched segment before continuing.

@matt a short explanation in the upgrade guide is probably warranted

Because it breaks things if we start messing with the path (we tried this in v1 - there are a bunch of other issues/forum posts but I can’t find them right now).

Matching a request is totally different from rewriting a request.

The proposal for handle_path is specifically for use cases where you want to both match AND rewrite a request based on its path prefix.

At least, impossible without reverting to the dreaded rewrite hacks :smiley:

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.