With caddy v1.0.3, is it possible to chain middlewares?
I’ve seen a comment for the Caddyfile that nested blocks are not allowed but the ServeHTTP signature and the AddMiddleware method are designed to let one middleware call another and then deal with the result.
The http.upload middleware is of particular interest to me. It can take a POST and create local files based on its configuration but is not designed to return a redirect or any indication to the user other than a return code like 201 or 204. It does return the http status codes per the ServeHTTP signature without writing them out so it is a higher level that writes the return code. How would an upper layer of middleware be
provisioned with a Caddyfile to write a body response?
Will v2 allow a middleware to be written that defines its own plugin interface - so plugins to plugins could be written?
The upload functionality for example begs at least two questions, what to do with the byte slices once they are taken from the request body, and how to respond with a response body. Both could be answered by other plugins that conformed to the interfaces that such a new upload middleware module defined.
The idea that a portion of the configuration can be passed to a module for it to unmarshal and do with as it needs is very nice.
Yes. This is how all of Caddy 2 is designed: plugins of plugins of plugins, but registration is centralized with Caddy’s core, all their state and config is managed for you (and each plugin validates its own config, etc). I think it’s a really neat architecture which I will be talking about at the Go meetup here in a couple months.
See the docs here: Home · caddyserver/caddy Wiki · GitHub (“module” roughly == “plugin”) - it’s basically just a LoadModule("name", rawConfig) and then a type assertion to the interface you expect that module to satisfy. This is how many existing v2 already work, like the reverse proxy, the encode middleware, and the TLS app.
So, Caddy knows about all “plugins of plugins” (“guest modules” – see the docs I linked, which explain these terms) but the “plugins” which load them (“host modules”) know how to access them and use them.