Caddy – The HTTP/2 Web Server with Automatic HTTPS
41–50 of 66 posts
Re: Caddy – The HTTP/2 Web Server with Automatic HTTPS
#42Earlier quoted context omitted.
I didn't notice that you can compile the source code yourself to avoid paying for the license. That seems to be a nice alternative.
Only if you're not using it for commercial stuff. If you're using it for commercial stuff you have to pay the $25/month
My understanding of their license page is different.
"If your company uses official Caddy binaries internally, in production, or distributes Caddy, a commercial license is required."
"If I build Caddy from source, which license applies?" "The source code is Apache 2.0 licensed."
Re: Caddy – The HTTP/2 Web Server with Automatic HTTPS
#43And it still doesn't obey the DNS specs. Specifically, the DNS RFCs define that, given no search domain, a relative hostname (e.g. google.com) is equivalent to its absolute hostname form (e.g. google.com.). This is used in SSL validation as well, a certificate valid for one is valid for the other, and in reverse. Every webserver SHOULD respond to both names identically, or redirect from one to the other. Let's try th…
You make it sound like the Caddy folks completely ignored the issue without providing a reason ("absolutely no reason", "doesn't even consider"). After looking into it, I find your post misleading and unfair, to say the least . Link to the issue for other users who, like me, were concerned by your post: https://github.com/mholt/caddy/issues/1632 According to the author, the issue is that (a) there are two RFCs that c…
[deleted]
Re: Caddy – The HTTP/2 Web Server with Automatic HTTPS
#44Earlier quoted context omitted.
Can't you build it from source?
I'm sure he can build it from source, but the "personal" license forbids using it for commercial purposes, so the point is moot.
The whole source is Apache-licensed, so there are no restrictions if you build & integrate it yourself.
The restrictive personal license applies to the official binaries.
Re: Caddy – The HTTP/2 Web Server with Automatic HTTPS
#45That's interesting! I wonder how it scales relative to, say, nginx.
Not comprehensive by any means, but some previous discussion: https://news.ycombinator.com/item?id=13357026
Re: Caddy – The HTTP/2 Web Server with Automatic HTTPS
#46Earlier quoted context omitted.
Can't you build it from source?
I'm sure he can build it from source, but the "personal" license forbids using it for commercial purposes, so the point is moot.
Those licences are only for the binaries. The source is Apache licenced and can be used for commercial purposes for free.
Re: Caddy – The HTTP/2 Web Server with Automatic HTTPS
#47As someone who is very very new to hosting their own services, this was an absolute piece of cake to set up. My first time dealing with reverse proxies and it took less than an hour to get going.
Good to know! As someone who's been called a senior SRE (I hate titles) and has been building platforms for years, it's great to see high quality software enabling new comers like your self to the field. Welcome! :-)
For someone that hates titles, you both managed to call yourself an 'SRE', and drop the fact that you've been 'building platforms for years'.
Just sayin'.
Re: Caddy – The HTTP/2 Web Server with Automatic HTTPS
#48And it still doesn't obey the DNS specs. Specifically, the DNS RFCs define that, given no search domain, a relative hostname (e.g. google.com) is equivalent to its absolute hostname form (e.g. google.com.). This is used in SSL validation as well, a certificate valid for one is valid for the other, and in reverse. Every webserver SHOULD respond to both names identically, or redirect from one to the other. Let's try th…
You make it sound like the Caddy folks completely ignored the issue without providing a reason ("absolutely no reason", "doesn't even consider"). After looking into it, I find your post misleading and unfair, to say the least . Link to the issue for other users who, like me, were concerned by your post: https://github.com/mholt/caddy/issues/1632 According to the author, the issue is that (a) there are two RFCs that c…
I don't see two conflicting rfcs. Can you point them out? I saw a link to a Mozilla thread discussing how they should do normalization, but nothing about not supporting the fully qualified format. Cross origin rules don't apply for looking up a virtual host.
Also, the concerns over security the caddy developer make aren't clarified and probably don't exist.
No dot has 2 possible meanins and with dot has one _to the resolving application_. To the server resolving a virtual host there is only one for both.
Re: Caddy – The HTTP/2 Web Server with Automatic HTTPS
#49Earlier quoted context omitted.
What do you mean by locally? If you want HTTPS automatically then the site must be publically available so that LetsEncrypt can verify the domain and grant the certificate. If that's not possible then you'll have to use the DNS challenge and setup a provider plugin. It doesn't matter where the backend points and you can use it to serve a docker container if you want, but that's different from the the host/frontend ad…
Locally in the sense of a local development server. The issue is that there wouldn't be a real DNS record pointing at the machine (well, unless you added one to point at your external IP address, but that's a pain for teams). I guess if Let's Encrypt needs to verify the domain it won't be possible...
Let's encrypt can issue certs without needing a public route to your machine if you use the dns challenge. Here's what I do:
1. Add a public A record (or host file) local.mydomain.tld to 127.0.0.1.
2. Host my dns with cloudflare (other providers have plugins too), and install the caddy plugin to do the dns challenge for certs.
3. Caddy can then get certs for local.mydomain.tld and serve them locally.
Re: Caddy – The HTTP/2 Web Server with Automatic HTTPS
#50That's interesting! I wonder how it scales relative to, say, nginx.
It scales fine… if you don’t already know the answer to that question, none of the web servers you choose are the bottle-neck to your site. ;-)
I'm glad tour aware of the performance characteristics of gp's site!
But seriously, how do you know what their site is? Perhaps they're serving a lot of static content out of memory and a fat pipe, in which case the web server would in fact be a bottleneck.