Hi all – What are the differences between Caddy and net/http, golang’s built-in http(2) server?
Big question, I know, but I wanted to put it front and center. In making deployment decisions – and articulating deployment and purchase decisions to stakeholders – we need to be able to explain the delta between Caddy and what Go provides by default. This is especially true because Caddy imports net/http in pretty much every source file we’ve seen, so it looks like a tight relationship.
The features page doesn’t go into it. It would be helpful if Matt or anyone could highlight the things Caddy adds to net/http, or things it enhances. If there’s a write-up already, a link would be awesome (nothing came up on Google, but it’s not easy to Google).
Cool question. Interested in an answer from someone with a comprehensive grasp of Caddy source. I figured Caddy mostly just ties in lego, the assorted directives and plugins, and a conf parser for server types (Caddyfile, Corefile, etc), simply making use of net/http off the shelf to do the actual web serving.
It’s not that big of a question. Matthew’s right: Caddy’s just a glorified wrapper over Go’s net/http and crypto/tls packages.
Caddy net/http.
There are a few things we take into our own hands. For example, we implement our own static file server and reverse proxy. But these are originally based on code in the standard library, now heavily modified. This quasi-integrated relationship changes over time, but it shouldn’t matter to the user either way.
What users should know is that Caddy is written in Go and, as such, benefits from all the Go advantages of each new Go version (optimizations, bug fixes, etc.) but also (and this is less common, or usually only noticable with edge cases) limitations of what the standard library exposes or even bugs.
For an example of the latter, Caddy couldn’t customize TLS settings for each site until Go 1.8. But in Go 1.8, it became possible to load a TLS configuration based on SNI. Cool. For an example of the former, Caddy magically uses HTTP/2 for all HTTPS connections by default because Go 1.6+ net/http does too. That, and another example: Caddy’s graceful shutdowns are now powered by Go 1.8’s server shutdown method, which didn’t exist before (we rolled our own).
For some examples of what Caddy does that has essentially nothing to do with the standard library: MITM detection, Caddyfile parsing, TLS certificate loading and management (lego helps with this at the protocol level but we do all the higher logic), Markdown rendering (blackfriday), signal handling, and much more.
In general, we try to use the standard library as often as possible. It’s very well engineered, thoroughly vetted by many experienced maintainers, under test, and quite stable.
