I use the API to programatically configure caddy. My case is a docker instance and caddy being used as a proxy to the containers.
The process is well suitable for caddy’s architecture:
getting the list of containers and their attributes
for each of them building a self-contained route (what I mean by that is that the definition of the route contains all the information about that reverse proxy endpoint)
adding all these routes as a list/table to apps.http.servers.myserver.routes
This is perfect except for one thing: when I have an exception to HTTPS (one of the endpoints being excluded from HTTPS), this configuration goes to apps.http.servers.myserver.automatic_https.skip in the form of a list/table of the sites.
This heavily complicated the idea of having a set of self-contained routes which can then be added to the configuration (the routines which deal with the routes not only need to return the routes but also extra information).
This is less a question and more of a comment about the consistency of the structure of the configuration.
It’s simply because automatic https isn’t a route. It’s some logic that runs at the HTTP app level that manipulates the config internally just before startup to automatically turn on HTTPS if certain conditions are met. Its behaviour can be configured per-server though for additional flexibility.
You can read the logic here (it’s well commented so it should be pretty clear what it’s doing)
Or, it simplifies it – it’s not so much Caddy that has an inconsistency here, but this:
That is the inconsistency/exception in the process.
As Francis said, auto HTTPS isn’t a “route”. It uses a route, but only to redirect HTTP to HTTPS, which happens on another listener. Most of automatic HTTPS is server configuration other than setting up HTTP handlers.