And sometimes it send us a lot of traffic to the URL. Instead of that I thought it will be better to send the “ASK” into a local file in the server.
This file will include an update list of all the valid domains in the system. Maybe Caddy can also save the file in is memory for some seconds so it will prevent easy DDOS attack.
I like this idea, and if you could also do something similar for the caddyfile root, make root file:// that points to a file that maps domains to directories, then I could easily dump apache for one of my applications.
The thing I don’t like about the file:// idea is that we need to come up with a particular format the file needs to be in for us to read. More code in Caddy to maintain. More ways for things to go wrong. People will complain about file permission issues, inevitably.
Setting up a simple HTTP server microservice is dead-simple. You can do it in any programming language you prefer. Standard request format with the ?domain= query param. You can implement your own caching logic as you see fit (whereas we’d have to be opinionated with the file approach).
Yes, but if domains are being added dynamically, you need to rewrite the caddyfile and restart caddy or use the json api which is complicated. A file format is simpler assuming changes to the file would be reflected in caddy without a restart.
In Apache they have a rewritemap function where you can create a file with domain to root mappings.
The format is simple… one domain per line. Setting up a simple http server microservice is a lot more effort than creating a file for the user of Caddy and you are adding more complexity to the infrastructure that people need to run a caddy service. The elegance of Caddy is it is so simple and it works.
root * /{host} works great if the directories are named after the domain. Great solution and I have used this and it works great.
But if the directories don’t match the domain, then a map is nice when it is static, but if you are dynamically adding domains, you need to restart caddy. And if the domain update is issued from a client request using caddy/php, php can’t restart caddy as caddy won’t restart until the php request is completed. It sort of seems that restarting caddy to add or remove a domain isn’t ideal. It is sort of a catch 22. Plus rewriting caddyfile on the fly doesn’t feel right to me.
Well that is pretty slick! Thanks for sharing that!!!
However, still the issue with updating the caddyfile each time you add/remove a domain. And while a bash script is great, the issue of when the update is initiated from php invoked from caddy, there is a deadlock of caddy waiting for the php to complete before it reloads and php waiting for caddy to restart.
Sorry, I used restart and reload interchangeably. I will try and be more precise in the future.
Can I send a https request to caddy that runs a php program that executes a bash script that will update the caddyfile and reload caddy while the php program is running once the bash script completes, the php program can continue executing statements? It is my understanding that caddy won’t reload while the php program is running.
You teach me so much! Thanks! But once I issue the fastcgi_finish_request I can no longer communicate with the client from the php program. It does not seem like a clean approach, but I think it is a workable solution.