caddyconfig: Add new handle_path directive for easier subpath grouping

[francislavoie]

Implementation of #3266

This is incomplete/non-functional, still has debug prints etc. The general idea is there but it's not working as expected.

Edit: Figured it out! Didn't realize I should be using h.NewRoute() which does the trick.

Caddyfile:

:80

handle_path /api/v1 {
    respond "API v1"
}

file_server

JSON:

{
  "apps": {
    "http": {
      "servers": {
        "srv0": {
          "listen": [
            ":80"
          ],
          "routes": [
            {
              "match": [
                {
                  "path": [
                    "/api/v1*"
                  ]
                }
              ],
              "handle": [
                {
                  "handler": "subroute",
                  "routes": [
                    {
                      "handle": [
                        {
                          "handler": "rewrite",
                          "strip_path_prefix": "/api/v1"
                        }
                      ]
                    },
                    {
                      "handle": [
                        {
                          "body": "API v1",
                          "handler": "static_response"
                        }
                      ]
                    }
                  ]
                }
              ]
            },
            {
              "handle": [
                {
                  "handler": "file_server",
                  "hide": [
                    "../../../../caddy/Caddyfile-handle-path"
                  ]
                }
              ]
            }
          ]
        }
      }
    }
  }
}

[francislavoie]

This is a bit funky, but aside from changing how ParseSegmentAsSubroute works to avoid the extra h.Next(), I'm not sure what to do.

[zakcutner]

This is super cool, thanks! My only concern is that I actually find the name handle_path slightly confusing as it doesn't express that it matches a prefix (rather than an exact match as usual) and that it strips the prefix rather than simply handling it — which I think is the killer behaviour here 😎

I don't have an amazing understanding of all the directives so perhaps this wouldn't make sense, but how about splitting up this functionality into two options which could be added to the existing handle directive?

1. handle /foo prefix { ... } would cause /foo* to be matched rather than /foo.
2. handle /foo strip { ... } would cause the first argument, /foo, to be stripped after matching.

Then, the functionality of handle_path /foo { ... } that you have implemented could be expressed using these options as handle /foo prefix strip { ... }.

Alternatively, maybe it would be cleaner to add the prefix option to the path matcher in a similar way to how NGINX does in location blocks (the syntax location /foo { ... } vs location = /foo { ... }). I think it also makes more sense for 'prefix mode' to actually be enabled by default as (just from my intuition 😬) I imagine this is the more common use case.

[mholt]

Thanks again @francislavoie -- I like where this is going. I left a few comments about how we handle and what we should expect of the matcher token.

[mholt]

@zakcutner I propose we update this PR to accept a first argument that looks and acts like a standard path matcher token, i.e. handle_path /foo/* ... where we trim the * if present. Omitting the * would still be an exact match, and it would still strip it, essentially turning the path into /. This way it should act like all other path matchers, just with prefix stripping. How's that?

[francislavoie]

I agree with that - I'll try to finish this one off soon.

[zakcutner]

Sound good 😃 It looks like this will solve a pretty specific use case so I agree there's not much point generalising it further like I was suggesting, particularly as it seems like that would be a lot of work. Thanks again to both of you for all your work on this!

[francislavoie]

Alright, cleaned this up. I think this is done?

[mholt]

Great, this LGTM!

@zakcutner can you try this out? And then we will merge it if it works for you.

[zakcutner]

Just tried this out and it works great, thank you both 😃

[mholt]

Nice work on this one @francislavoie