Meaning, if aaaa is true, then redir bbbb to cccc.
=====================================
But in caddy2, it doesn’t work. (That configuration will redirect everything to a path called “/301/”)
So I have to make a named matcher called @aaaa in the new caddyfile:
(Note that I have specified path /b* - the asterisk effectively makes it a prefix matcher. This was the default, implicit behaviour in v1. If you want to redirect away from ONLY /b and not /b/foo or /bfoo, use path /b without an asterisk.)
Wow, of course it works! I totally get it! I was over-thinking, stupid me. Thank you so much!
I have a little suggestion: give more config examples in docs, for as many as the real scenarios you can think of, please.
It is because usually, I find a piece of a good example from the docs (or from the forum), worths hundreds of words of technical explanations. Users truly benefit from these.
I get that . I did pasted my caddyfile then decided to delete it, then I strip my question down to the core. I just don’t want to waste everyone’s time to read my 280 lines caddyfile, and it also take me ages to replace all the urls/names/certs in it.
This is okey, for a case question like this, right?
Where do you think an example like this should go, in the docs, exactly? Might see if we can’t do just that.
We love to see people suggesting examples and stuff for the docs. Caddy v2 is still very freshly released, and the docs are still pretty fresh, too. There’s only so many examples you can think of when you’re writing documentation from scratch, so adding examples as we come across them is super important.
It’s OK here, since we could infer from the abstract, and it was a simple issue.
That said, it’s equally OK here to post the whole 280 lines. If you throw em in a code box, it scrolls, so it’s neat regardless. And honing down on the relevant part of the Caddyfile - or a log, or a unit file, or anything like that - is pretty easy.
The rest of it there is just really, really helpful for context, and double checking that other moving parts aren’t interfering or causing problems - obviously not strictly necessary here, but almost universally useful info and we’ve had plenty of times where missing some of that context has caused us to draw the wrong conclusions and made a thread ten times longer than it needed to be.
Sorry it took me a while to let this question sink in and figure out an answer.
The thing is, for a “caddy2 expert” like you, making a caddyfile must seem so easy. Every section and every parameter are so plain and obvious.
But for a non-caddy website developer, it is still a bit headache to piece together a working caddyfile from the documentation + old forum posts here and there. Especially after 8 hours coding work, learning to fully master a new “format concept” is no fun. (Lots of users just wanna give Caddy a try at the beginning, before consider to production)
The best idea I can think of, is making a new doc section name “Caddyfile Examples”
Then throw users dozens caddyfile “full examples” covering most frequent use cases, like:
You need to setup a wordpress site behind the cloudflare? Here you go:
You need Caddy to load balancing and reverse proxy AWS site farm? Here you go:
yoursite.com {
........
}
The advantages are:
If 95% of users can find a full official example for his/her case, and be able to apply it in minutes straight, it will make Caddy much more appreciated and popular.
It becomes the real “feature showcase”, showing the world how many things Caddy can do and what Caddy has achieved.
It is a central place for Caddy officially manage its syntax in case of future updates (unlike the massive examples in old forum posts, once it is out-dated no one will refresh it.)
For other parts of the documentation, if an example is needed, just link/anchor to show the user a full example of the real-world use case (I believe every function of Caddy is made with actual usage in mind, right?)
If an issue is frequently seen in the forum, update a good example in the page instead of each forum post. It will help the broad future audience and potentially reduce the forum management load.
That’s what our wiki category in the forum is for - we even link to it in the header: Wiki - Caddy Community
This is better since anyone can contribute to the wiki at any time, without being bottle-necked by code review or site deployments.
I think a huge part of this problem is referring to old posts / random pages on the Internet that are about Caddy 1 and assuming it will work in Caddy 2. It might, but probably not.
I like this… maybe an Advanced Caddyfile Tutorial or something?
This sounds like what our wiki can and should be.
Just to be clear, our main goal with Caddy 2 was to make it technically sound, not to make it easy to use. That was our #1 (non-technical) problem in Caddy 1: pretending that web servers could be easy. They aren’t, and they can’t be, because the Web and its infrastructure is inherently complex. In practice, Caddy 2 configs are usually pretty elegant, and (with adapters) elegant, short, and easy to read/write, but it is not a toy – there is a learning curve, just like any other powerful tool.
Not to say that you can’t use it easily, like you can still deploy a simple production reverse proxy with caddy reverse-proxy --from example.com --to localhost:8080 with no config files at all, or a moderately-complex site with ~5 lines of Caddyfile – all of that still holds true in v2. I just don’t think going in with assumptions from v1 is a good idea, especially the assumptions that v2 works the same way as v1 and that there is no learning required.
If you can jump out of what you do and pretend yourself as a person who is totally new to Caddy, and read quick-start again, you will find if very wordy and confusing:
(Using API? Or using a Caddyfile? Why are these? Which one to choose for my simple test server? .json or not? ok, caddyfile seems easier, follow the guide, Caddy can “Hello world” now, then what? how to serve other files or php? search other parts of docs…why don’t you guys just simply give me a fully working config example instead?)
I remember the way I learn nginx is, get right to something like this Full Example Configuration | NGINX … a full config explains everything itself! I read it, copy-paste-modify, and the server is running.
There is no need to step-by-step showing how to respond “hello world”.(experienced user will ignore it and noob user will find it totally no-help). Throw users some well-written / production-ready config examples please. Users will learn everything from them much faster and much easier.
Which 5 lines? where can a new user find these 5 lines from the official documentation?
WOW, this actually explains A LOT. I can tell from my heart that v2 is on the right path. Please keep up good work! You guys rock!
API Caddyfile How to choose JSON Links to Caddyfile tutorial Links to JSON/API tutorial
This is what we want users to do – we want users to be familiar with documentation, where to find answers, and how to learn how the software works for themselves. We prefer this.
Do you realize how many possible combinations there are? How many “fully working configs” there are, and not to mention the fact that what is suitable for one user won’t be for another? “Fully working configs” are not exactly something you can mass-produce. I mean, if you want “fully working” as in “minimal working” we can give you this config:
example.com
file_server
… but is that what you want? How are we supposed to know that? And how do we tailor this to everyone’s specific needs?
That config does one very, very specific thing. It absolutely is not something that works for everyone.
PS. That part of the nginx site is their wiki. And we have a wiki, too. Feel free to contribute!
All our examples are “production-ready,” which means something different to everyone.
Depends what you want to do…?
Sorry we deceived everyone with v1. It’s one of my biggest regrets.
. I did pasted my caddyfile then decided to delete it, then I strip my question down to the core. I just don’t want to waste everyone’s time to read my 280 lines caddyfile, and it also take me ages to replace all the urls/names/certs in it.
API