(Incidentally, I really hope my little Digital Ocean droplet can handle the load. Wouldn't that be ironic? Anyway, if you have trouble, try the plain HTTP/1.1 site or the GitHub project page: https://github.com/mholt/caddy)
Additionally, we have 24x7 chat, ask for Jonathan! :-)
Around two years ago a SolusVM zero day allowed attackers to:
- Partially or fully wipe most VPS, many of which could not be recovered
- Gain access to the database, including plaintext root VPS passwords, first name, last name, email
Not saying DigitalOcean is a fortress or anything but it hasn't been compromised on anything like this kind of scale.
We do not have any locations offshore yet, however we are looking to expand and open new datacenters in the years to come.
The biggest problem I've encountered with it is not being able to set up certain iptables rules without a particular setting on the OpenVZ host being enabled (which often requires a support ticket).
To put it simply, OpenVZ works similarly to Docker rather than VirtualBox or VMWare and comes with similar benefits and limitations.
Your docs page 404s for me every other refresh and doesn't load with any CSS. I'm guessing this is a load problem?
Edit: Managed to load it with styling this time, it looks great :)
Feel free to open an issue about it!
That the actual web server in use is:
Which isn't to detract from the Caddy project which offers a tidy set of configuration options so that the lib is more like an Nginx executable with config files.
Perhaps the README can be updated though, as "Caddy binaries are available for nearly every platform and has no dependencies" is a bit misleading. The binary produced by Go may not have dependencies, but the Go code itself has a few large dependencies.
I'd probably opt to change the phrasing to be clear that you're using these other libs, simply because they are well-proven, have a lot of mindshare, and that you're standing on the shoulders of giants and bringing it all together in an out-of-the-box server that people can immediately use is actually a great story.
But also, in terms of Separation of Concerns, it doesn't seem like the server should be responsible for compilation tasks when it doesn't need to be. It would be much better to move that out into a separate tool for compiling Markdown to HTML (perhaps on-save, for authoring) - many of those already exist. Or, if you really wanted to perform compilation during a request, it could at least be moved out of the server core, into a FastCGI script (perhaps something like https://menteslibres.net/luminos/).
Oh, and that whole method of using a `Caddyfile` at the root of the project, for configuration, is quite nice.
It has random load balancing, glob patterns for hosts, SSH proxying (like sslh) and, most importantly, proxying to UNIX sockets. And less code.
Maybe you could use my code to implement some of these features :-)
- rc4 acceptance
- Session resumption (caching) No (IDs empty)
- no OCSP stapling
- Next Protocol Negotiation (NPN) Yes, but not signalling a http/1.1 fallback
Also, if you want to convince me to switch to Caddy from Nginx, perhaps a page with succinct explanation of its advantages would be helpful?
Lastly, this is just my opinion, but I don't want my web server to have a Markdown interpreter in it. That's not a job for the web server. It's very easy to put a very simple index file in front of Markdown to provide that functionality.
Thanks for the rest of your feedback. I agree that a list of advantages needs to be more available. I'm looking forward to making that soon!
Also, do you have any plans to make Caddy support domain proxying (or whatever it's called) where you can specify that requests for certain sites should be proxied to a service running on another host + port combination (if it doesn't support that already)?
Definitely a cool project though. I'll keep an eye on it. Keep up the excellent work!
Caddy does have basic reverse proxy functionality. Something like what you're suggesting could be `proxy / localhost:8005` - but this middleware will need more attention.
There exists a native Go package to render GFM, see second from the top at https://github.com/avelino/awesome-go#text-processing.
Someone has already opened an issue about it at https://github.com/shurcooL/go/issues/19, and I'm planning to take care of it.
Edit: Oh, I guess that was you.
Returning a non 200 or 300 redirect code.
Deciding status on more than server name and path
Finally, there was discussion earlier on HN on how to write plugins which communicate via sockets... Might be an interesting addition to consider adding to your middleware API.
One recommendation I would make is the addition of some simple load balancing, even round robin would be great.
404 Not Found
Edit: Following the link from the homepage works, but hitting F5 or loading it without a referrer provides a 404. Weird.
Is this the first http2 server released?
Looks good otherwise!
With Caddy or another solution.
Nginx+ claims it does so (I didn't purchase it). HAProxy can be configured to use sticky sessions.