website

https://caddyserver.com/docs/caddyfile/directives/templates https://github.com/caddyserver/website/blob/master/src/docs/...

Oh, just saw this. You wrote your comment while I wrote mine. If you can enumerate specifically what you want to see, please submit it to our issue tracker: https://github.com/caddyserver/website Generally we encourage examples in our community wiki though: https://caddy.community/c/wiki/13 -- much easier to maintain that way.

What do you struggle with about the documentation or "more complex setups"? I was just on the phone recently with Stripe who has a fairly complex, large-scale deployment, and they seemed to have figured it out with relative ease. I'm currently on a push to improve our docs, especially for beginners, so feel free to review the changes and leave your feedback: https://github.com/caddyserver/website/pull/263

I wrote up a few notes on my Caddy setup here https://muxup.com/2022q3/muxup-implementation-notes#serving-... which may be a useful reference if you have a static site and wanted to tick off a few items likely on your list (brotli, http3, cache-control, more fine-grained control on redirects). I don't think performance is ever going to matter for my use case, but one thing I think is worth highlighting is the quality of the community and maintainership. In a thread I started asking for feedback on my Caddyfile (https://caddy.community/t/suggestions-for-simplifying-my-cad...), mholt determined I'd found a bug and rapidly fixed it. I followed up with a PR (https://github.com/caddyserver/website/pull/264) for the docs to clarify something related to this bug which was reviewed and merged within 30 minutes.

Yes, the docs have been updated at https://github.com/caddyserver/website but haven't been deployed yet. There is a new protocols option: protocols h1 h2 will disable Http/3 but leave 1.1 and 2 on.

> Is there a static site generator out there that doesn't require a ridiculous build process every time I do an update? I am experimenting with Caddy's template functionality [0] in my pursuit of making dependency-free and buildless websites. Caddy's templates are inspired by the Server Side Include (SSI) functionality in Apache and Nginx, except it uses Golang's syntax. I have made several websites in Hugo and find it pleasantly similar, only more bear-bones. Although Caddy is serving static sites to the browser, it is technically more like using a dynamic scripting language like PHP on the server. I guess Caddy templates outperform PHP by a large margin because it is written in Golang and compiled, but I have never tested this hypothesis. Funfact: Caddy's entire website is written with Caddy's template system and the source code is avai

Rather than JS, one can use Caddy's built-in template engine [0] to include headers/footers server-side (but way more powerful than SSI): {{include "/includes/header.html"}} No JS, no external build step, still static HTML files -- just pieced together by the server at request-time. Works great [1]. (Or use plain Markdown, and have Caddy's template engine render it as HTML on-the-fly. Your choice.) [0]: https://caddyserver.com/docs/modules/http.handlers.templates [1]: https://github.com/caddyserver/website/blob/master/src/docs/... <-- Try doing that with SSI

Could you be more specific about these complaints? What examples don't work? We can't work on improving the docs if we don't get specific and actionable feedback. The docs are found at https://github.com/caddyserver/website if you want to propose any changes. You can also come ask for help on the forums https://caddy.community if you can't find what you're looking for.

Could you be more specific about these complaints? What examples don't work? We can't work on improving the docs if we don't get specific and actionable feedback. The docs are found at https://github.com/caddyserver/website if you want to propose any changes.

Protip: you can click almost everything in code blocks in the docs. For example, if you click `[<matcher>]`, it brings you right to the request matcher syntax section, which explains what you can fill in there. It would be redundant to write on every page what you can use as a matcher. The Caddyfile reference docs assume you've read https://caddyserver.com/docs/caddyfile/concepts which walks you through how the Caddyfile is structured, and it'll give you the fundamentals you need to understand the rest of the docs (I think, anyway). If you think we need more examples for a specific usecase, we can definitely include those. Feel free to propose some changes on https://github.com/caddyserver/website, we could always use the help!

This is a cool article. Unfortunately the described syntax only covers Caddy V1. Caddy has been on V2 since early 2020, and the V1 examples won't work on V2 for markdown usage. These links can help with Caddy V2 Markdown usage: https://caddyserver.com/docs/caddyfile/directives/templates https://github.com/caddyserver/website/blob/master/src/docs/... https://caddy.community/t/markdown-support-in-v2/6984 Thanks to the Caddy team for such an excellent program!

Yep, just enable templates with the 1 line of config and then put {{markdown "here"}} in your web pages and there you have it. Caddy's entire docs are powered by this kind of templating, it's quite useful: https://github.com/caddyserver/website/blob/master/src/docs/...

Regarding Caddy directive docs, there's examples right at the bottom. What are you missing, exactly? If you could be more specific, we can address it. But as-is, your comment is too vague to be actionable. Feel free to open an issue on https://github.com/caddyserver/website with specific examples you think are missing. Regarding empty 200 responses, this is because "Caddy worked as configured". A 404 Not Found would be incorrect, because there was no attempt to "find" anything. A 400 would be incorrect, because the request was probably fine. A 500 would also be incorrect, because there was no error. The only option remaining, really, is an empty 200 response. It's the user's responsibility to make sure the configuration handles all possible requests with a handler that does what they want. Regarding fail-fast on cert issues, the problem w

See also Caddy web server: Rendered: https://caddyserver.com/docs/caddyfile Markdown: https://github.com/caddyserver/website/blob/master/src/docs/... Unofficial How-To thread: https://caddy.community/t/markdown-support-in-v2/6984

Ah, we actually have one of these at Caddy: https://caddyserver.com/docs/architecture (The filename on disk is literally "architecture.md" -- it is a Markdown file rendered by Caddy's template handler: https://github.com/caddyserver/website/blob/master/src/docs/...) It could use some improvement, but it's been really great for helping people learn how Caddy 2 works at a high level. Beyond our docs, I always encourage new contributors to thoroughly explore the godoc and code: it's very well-commented and organized, especially once you know how it all comes together. A single document will never be sufficient. But it can help you map between concepts and code. Code search is also invaluable for this; I recommend Sourcegraph: https://sourcegraph.com/github.com/caddyserver/caddy Edit: One other valuable piece is explaining why the architectur