95b6ac44a6
This is mainly a problem with the default behaviour of the Caddyfile's `handle_errors` routes, but it's kinda tricky to solve well. I went with an approach that involves a smidge of magic which might not really be desirable. See https://caddy.community/t/problem-with-basicauth-handle-errors/12243/9 for context. So we do already have a default fallback for error routes, i.e. `errorEmptyHandler` in `caddyhttp.go` which is always configured as the last handler in the chain (implicitly, not visible in the config). The problem is that when subroutes come into play with `"terminal": true`, then this fallback handler will never be reached. This is the case when the Caddyfile generates a config which has a host matcher from a site block (which is most of the time) when the user configured `handle_errors` to handle specific errors (such as 502s or 404s to serve HTML pages for those, etc). If other errors, like `basicauth`'s 401s are emitted in that case, then the result is that the default of HTTP status 200 will be served instead of the 401, which breaks `basicauth` completely. The fix I went with is to make the Caddyfile adapter append special `error` handlers inside of the `handle_errors` subroutes which throw error `-1`, which `server.go` then picks up, and seeing `-1` responds with the original error code of `401` instead. The `-1` thing is the aforementioned magic. At first, I had this implemented with `static_response` setting the StatusCode to `{http.error.status_code}`, but it didn't feel right to use a placeholder because it's inherently slightly less efficient, and it wasn't 100% correct because non-handler errors wouldn't be handled as 500s properly I think (because if it's not a `HandlerError`, then `http.error.status_code` doesn't exist, so it would maybe try to write an the placeholder replacement result of an empty string as `0` for the status code). |
||
|---|---|---|
| .github | ||
| caddyconfig | ||
| caddytest | ||
| cmd | ||
| modules | ||
| notify | ||
| .gitignore | ||
| .golangci.yml | ||
| .goreleaser.yml | ||
| admin.go | ||
| admin_test.go | ||
| AUTHORS | ||
| caddy.go | ||
| caddy_test.go | ||
| context.go | ||
| context_test.go | ||
| duration_fuzz.go | ||
| go.mod | ||
| go.sum | ||
| LICENSE | ||
| listeners.go | ||
| listeners_fuzz.go | ||
| listeners_test.go | ||
| logging.go | ||
| metrics.go | ||
| modules.go | ||
| modules_test.go | ||
| README.md | ||
| replacer.go | ||
| replacer_fuzz.go | ||
| replacer_test.go | ||
| sigtrap.go | ||
| sigtrap_nonposix.go | ||
| sigtrap_posix.go | ||
| storage.go | ||
| usagepool.go | ||
a 
project
Every site on HTTPS
Caddy is an extensible server platform that uses TLS by default.
Releases · Documentation · Get Help
Menu
Powered by
Features
- Easy configuration with the Caddyfile
- Powerful configuration with its native JSON config
- Dynamic configuration with the JSON API
- Config adapters if you don't like JSON
- Automatic HTTPS by default
- ZeroSSL and Let's Encrypt for public names
- Fully-managed local CA for internal names & IPs
- Can coordinate with other Caddy instances in a cluster
- Multi-issuer fallback
- Stays up when other servers go down due to TLS/OCSP/certificate-related issues
- Production-ready after serving trillions of requests and managing millions of TLS certificates
- Scales to tens of thousands of sites ... and probably more
- HTTP/1.1, HTTP/2, and experimental HTTP/3 support
- Highly extensible modular architecture lets Caddy do anything without bloat
- Runs anywhere with no external dependencies (not even libc)
- Written in Go, a language with higher memory safety guarantees than other servers
- Actually fun to use
- So, so much more to discover
Install
The simplest, cross-platform way is to download from GitHub Releases and place the executable file in your PATH.
For other install options, see https://caddyserver.com/docs/install.
Build from source
Requirements:
For development
Note: These steps will not embed proper version information. For that, please follow the instructions in the next section.
$ git clone "https://github.com/caddyserver/caddy.git"
$ cd caddy/cmd/caddy/
$ go build
When you run Caddy, it may try to bind to low ports unless otherwise specified in your config. If your OS requires elevated privileges for this, you will need to give your new binary permission to do so. On Linux, this can be done easily with: sudo setcap cap_net_bind_service=+ep ./caddy
If you prefer to use go run which only creates temporary binaries, you can still do this with the included setcap.sh like so:
$ go run -exec ./setcap.sh main.go
If you don't want to type your password for setcap, use sudo visudo to edit your sudoers file and allow your user account to run that command without a password, for example:
username ALL=(ALL:ALL) NOPASSWD: /usr/sbin/setcap
replacing username with your actual username. Please be careful and only do this if you know what you are doing! We are only qualified to document how to use Caddy, not Go tooling or your computer, and we are providing these instructions for convenience only; please learn how to use your own computer at your own risk and make any needful adjustments.
With version information and/or plugins
Using our builder tool, xcaddy...
$ xcaddy build
...the following steps are automated:
- Create a new folder:
mkdir caddy - Change into it:
cd caddy - Copy Caddy's main.go into the empty folder. Add imports for any custom plugins you want to add.
- Initialize a Go module:
go mod init caddy - (Optional) Pin Caddy version:
go get github.com/caddyserver/caddy/v2@versionreplacingversionwith a git tag, commit, or branch name. - (Optional) Add plugins by adding their import:
_ "import/path/here" - Compile:
go build
Quick start
The Caddy website has documentation that includes tutorials, quick-start guides, reference, and more.
We recommend that all users -- regardless of experience level -- do our Getting Started guide to become familiar with using Caddy.
If you've only got a minute, the website has several quick-start tutorials to choose from! However, after finishing a quick-start tutorial, please read more documentation to understand how the software works. 🙂
Overview
Caddy is most often used as an HTTPS server, but it is suitable for any long-running Go program. First and foremost, it is a platform to run Go applications. Caddy "apps" are just Go programs that are implemented as Caddy modules. Two apps -- tls and http -- ship standard with Caddy.
Caddy apps instantly benefit from automated documentation, graceful on-line config changes via API, and unification with other Caddy apps.
Although JSON is Caddy's native config language, Caddy can accept input from config adapters which can essentially convert any config format of your choice into JSON: Caddyfile, JSON 5, YAML, TOML, NGINX config, and more.
The primary way to configure Caddy is through its API, but if you prefer config files, the command-line interface supports those too.
Caddy exposes an unprecedented level of control compared to any web server in existence. In Caddy, you are usually setting the actual values of the initialized types in memory that power everything from your HTTP handlers and TLS handshakes to your storage medium. Caddy is also ridiculously extensible, with a powerful plugin system that makes vast improvements over other web servers.
To wield the power of this design, you need to know how the config document is structured. Please see our documentation site for details about Caddy's config structure.
Nearly all of Caddy's configuration is contained in a single config document, rather than being scattered across CLI flags and env variables and a configuration file as with other web servers. This makes managing your server config more straightforward and reduces hidden variables/factors.
Full documentation
Our website has complete documentation:
The docs are also open source. You can contribute to them here: https://github.com/caddyserver/website
Getting help
-
We strongly recommend that all professionals or companies using Caddy get a support contract through Ardan Labs before help is needed.
-
A sponsorship goes a long way! If Caddy is benefitting your company, please consider a sponsorship! This not only helps fund full-time work to ensure the longevity of the project, it's also a great look for your company to your customers and potential customers!
-
Individuals can exchange help for free on our community forum at https://caddy.community. Remember that people give help out of their spare time and good will. The best way to get help is to give it first!
Please use our issue tracker only for bug reports and feature requests, i.e. actionable development items (support questions will usually be referred to the forums).
About
The name "Caddy" is trademarked. The name of the software is "Caddy", not "Caddy Server" or "CaddyServer". Please call it "Caddy" or, if you wish to clarify, "the Caddy web server". Caddy is a registered trademark of Stack Holdings GmbH.
- Project on Twitter: @caddyserver
- Author on Twitter: @mholt6
Caddy is a project of ZeroSSL, a Stack Holdings company.
Debian package repository hosting is graciously provided by Cloudsmith. Cloudsmith is the only fully hosted, cloud-native, universal package management solution, that enables your organization to create, store and share packages in any format, to any place, with total confidence.