Does caddy v2 consider to support named http.handler?

I want to reuse http.handler by reference it’s name, like this:

{
    "apps": {
      "config": {
        "http": {
          "handlers": [
            {
              "name": "reqbody<10m",
              "config": {
                "handler": "request_body",
                "max_size": 10485760
              }
            },
            {
              "name": "accesslog_xxx",
              "config": {
                "handler": "accesslog_xxx"
              }
            },
            {
              "name": "proxy_to_xxx",
              "config": {
                "handler": "reverse_proxy",
                "headers": {
                  "request": {
                    "set": {
                      "host": [
                        "xxx.com"
                      ]
                    }
                  }
                },
                "upstreams": [
                  {
                    "dial": "xxx.com:80"
                  }
                ]
              }
            }
          ]
        }
      }
      },
      "http": {
        "servers": {
          "demo": {
            // ...
            "routes": [
              {
                "handle": [
                  {
                    "handler": "group",
                    "handler_names": [
                      "reqbody<10m",
                      "accesslog_xxx",
                      "proxy_to_xxx"
                    ]
                  }
                ],
                "match": [
                  {
                    "path": [
                      "/*"
                    ]
                  }
                ]
              }
            ],
            "write_timeout": "30s"
          }
        }
      }
    }
  }
}

thus, we can separate the handler definition and usage, I think it makes the configuration clearer, what do you think about?

About implementation, I came up with two options:

  1. like the above config, I implement it in a custom config App, which will be provisioned before http App;
  2. add a dummy route as first route, then define named handlers there.

I think if its best define named handlers in http block or server block? But it seems that there is no proper extension point.

1 Like

Great question – I looked at this very idea about a year ago when I started designing Caddy 2.

The more general way to frame this problem/question is whether parts of the JSON should be able to reference other parts of the JSON (at least, as a standard pattern or convention adopted by many parts of the config).

I went back and forth on this for days/weeks, and eventually I decided against it.

Compressing the logic/config of a particular part of the JSON into a string may be doable as you propose, but the point of the JSON isn’t for it to be handmade, at least, not from scratch. It’s just more for people to learn and more complexity to deal with. Also, referencing other parts of the JSON – which today we still do sometimes in exceptional cases (like log names, for example), is very complicated and leads to dependency tree issues during provisioning.

Our current design avoids most of these problems.

However, we have a very nice solution to be able to do what you want. What we ended up with instead is much better, I think: config adapters!

You can actually define any config format you want, and make it output Caddy’s native JSON. So if you want to write JSON like that, just write a config adapter to do it! That may be easier said than done, but it depends what you want to do. For example, a 1:1 conversion from YAML/TOML to JSON is a just a few lines of code (because libraries!), yet the nginx adapter is a few thousand lines of code.

So, feel free: invent your own config format – maybe some variant of the JSON – and make an adapter for it. It’s a simple interface: bytes in, bytes out.

1 Like

Indeed the config adapter is best solution for it, but there are some extra costs: development, maintenance, documentation etc. So maybe I prefer a custom module to do that.

Thank you for reply.

Ha, well, those costs exists either way, it’s just a matter of who pays them! :wink:

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