On the other hand, there are still some gaping holes - for example, to block (or allow) a 192.168.0.0/17 IPv4 subnet in Caddy, one needs to do all of below:
- Install an addon [1];
- Which used to require recompilation, with 0.9 release you can just click an option during download, yay!;
- Add 128 ranges to cover this single subnet: 192.168.0.0-255, 192.168.1.0-255, ...192.168.127.0-255. Configuration doesn't support subnets, only ranges. And only ranges in last octet, i.e. 192.168.1.0-255 (meaning 192.168.1.0/24), or implied ranges by trailing octet(s) omission, i.e. 192.168 (meaning 192.168.0.0/16) [2].
Oh, and ipv6 filtering doesn't exist at all.
[1] https://caddyserver.com/docs/ipfilter
[2] Which is mildly confusing notation too, since traditional UNIX inet_aton() call would interpret this as 192.0.0.168. Try typing "ping 192.168" on Linux.
Literally, one line (without needing root). Happy user.
But what if you want to serve different content to "blocked" users? i.e. login page, "we're sorry" page, redirect to read-only version of the site, reminder to connect to office VPN, anything like that...
Another example - more than one site on the same (server) IP, and only part of them are (client) IP-restricted.
Simply simple de facto features basically are called outstanding now?
Dynamic linking support was introduced in version 1.5, but it only works in GNU/Linux currently.
I expect it to eventually be available in all target OSes.
Caddy is very easy to use. You can download the build with what you want from their download page.
The nicest thing about it is very simple config file, TLS out of the box, automatically renew as well.
nope. That has been fixed with recent development versions that support loading plugins as shared libraries. For distros, that's very important because it allows them to ship much more configurable nginx packages as now plugins can be added as-needed.
Also, it makes distro packaging dreadful, since you can either ship nothing and be useless for nearly everyone, or ship everything and surprise users if they switch to the official builds and find out stuff is missing.
Nginx used to be as bad, but that's been fixed recently.
Personally Caddy is also not very useful for me, since I use a reverse proxy, and Caddy didn't seem very helpful there the last time I tried. Oh, and it would have been nice to be able to make it generate self-signed certificates for staging environments.
The issue is, that Go runtime has it's own ideas how the memory layout and stack layout should look like and these ideas are not compatible with __stdcall or __cdecl, so when calling C code, the runtime has to do a clean up. That used to involve a thread switch, now it involves a full register swap.
What Go does not allow, is putting Go code into dynamic library and then calling that from another go application - i.e. native go plugins for go apps.
go build -buildmode=c-sharedYes. Use this in your Caddyfile:
proxy /api 10.20.30.40:8080
No, QUIC is not supported at the moment: https://caddyserver.com/blog/implementing-http2-isnt-trivial
- and plain TCP for the front-end?
Yes, if you mean HTTP/1.x. Also, you can serve static files from the proxy itself. Everything not mentioned in explicit "proxy" directive would be served from local files in the same directory as Caddifile.
Caddy only has a QUIC server implementation. But I'm inclined to think that if you have a QUIC->TCP flow going on, you will lose most of the benefits of QUIC at the TCP part.
Of course, this makes sense because you have to compile the features in.
But, it would still be nice to have deployment automate-able. Maybe an Ansible role that combines the feature list you need and downloads it via an API.
It's the major, and only reason I quit and went back to nginx.
The repo does contain some init/service scripts for using Caddy on various Linux and BSD distributions. They are created and maintained by the community, but this combined with the binary should make it quite easy to package: https://github.com/mholt/caddy/tree/master/dist/init
Also, it seems somebody already started working on A Ubuntu 14.04 Caddy Repository: https://github.com/alexandreteles/caddy-repo
For what it's worth though FPM is awesome, and has made my life better a number of times. If you have to have software that isn't packaged and you aren't familiar with packaging, look into FPM.
This is a great project though, the author is young and talented.
Malloc/free are not cheap either.
What if you could slap something like Caddy in front of any API and provide authentication, analytics even billing out of the box.
- Rate limiting
- Billing
- Authentication and Authorization using OAuth or JWT
- Analytics/Metrics
- Geo Location
- TLS
- HTTP2?
- Image optimization
- Content minification
- Gzip
- Signaling Slack/Push/SMS
- Caching through cloud storage S3, BlackBlaze B2
- PostgRESTAs an example:
header / Cache-Control "no-cache, max-age=86400"
header /images/ Cache-Control "max-age=86400"
header /css/ Cache-Control "max-age=604800"
header /fonts/ Cache-Control "max-age=604800"
header /icons/ Cache-Control "max-age=604800"
So a request to a protected resource needs to be authenticated if not then redirect to a URL (login form).
If login is successful then a token is provided which can be used for authentication.
If a request is authenticated successfully then it can proxy to the resource.