Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Caddy – Open-source web server with automatic HTTPS

caddyserver.com

Post reply on HN
Print view View original

101–110 of 132 posts

Re: Caddy – Open-source web server with automatic HTTPS

#101

Post by francislavoie »

mook wrote: post #84
cunthorpe wrote: post #23

Earlier quoted context omitted.

To be fair, HTTPS by default makes perfect sense for a server. Of course the more complex the setup, the more you’re going against the defaults. It’s impossible to have defaults that work for everyone, so they chose the most common/desirable/sellable default.

I'd argue that HTTPS by default makes perfect sense for a _public facing_ server. For something on an internal network it doesn't make as much sense, especially since that makes using the default path for getting certificates difficult (can't get certs if you don't have DNS). I think what I'm trying to say is that Caddy was initially great for me (serving static files on the local network by IP address as an easy way…

FWIW, Caddy can act as its own CA, so it can issue certs for any private site, and you can add the root CA cert to any machines necessary.

> but hasn't been that for ages

Huh? It still is. This is all you need:

    :80 {
        root * /path/to/files
        file_server
    }

Re: Caddy – Open-source web server with automatic HTTPS

#102

Post by Xevi »

mholt wrote: post #79
Zababa wrote: post #73

Earlier quoted context omitted.

On the Caddy website ( https://caddyserver.com/ ) it says: > Caddy is both a flexible, efficient static file server and a powerful, scalable reverse proxy. > LIGHTWEIGHT For all its features, Caddy runs lightly and efficiently with relatively low memory footprint and high throughput . > STATIC FILES By default, Caddy will serve static files in the current working directory. It's so brilliantly simple and works fast .…

Not everything needs to be read as a comparison to other products. Adjectives have meaning without competition. They can be interpreted as ratios, for example requests / available memory, or load / latency. It's not always about putting down other products. Both can be fast. Both can be efficient. Both can be fast and light. Both can be "high" without one having to be low in order for it to be valid to call it "high"…

Then what do they mean to you? I think people are just trying to understand. What is "fast" and "efficient" to you? Where do you draw the line?

When it comes to tech in particular, things are pretty much always compared relative to each other, because there's very little other reference points. React is generally deemed as slow relative to Svelte. Rust is more efficient than Python at runtime. These claims mean very little in a vacuum, in fact I'd say that they are almost pointless. You can't base you business decisions on claims that haven't been backed up by data. And if you do, you might regret them later on.

Re: Caddy – Open-source web server with automatic HTTPS

#103

Post by francislavoie »

KronisLV wrote: post #88

In my eyes, Caddy is a lovely web server that works pretty well as ingress for container clusters (e.g. Nomad, Docker Swarm etc.). That said, i can't help but to feel that v1 was easier and in some ways nicer to use than v2, even though it's abandoned at this point. That said, i have certain grievances with most of the web servers out there. Apache2/httpd - actually decently usable even nowadays, but if the fragmenta…

Regarding Caddy directive docs, there's examples right at the bottom. What are you missing, exactly? If you could be more specific, we can address it. But as-is, your comment is too vague to be actionable. Feel free to open an issue on https://github.com/caddyserver/website with specific examples you think are missing.

Regarding empty 200 responses, this is because "Caddy worked as configured". A 404 Not Found would be incorrect, because there was no attempt to "find" anything. A 400 would be incorrect, because the request was probably fine. A 500 would also be incorrect, because there was no error. The only option remaining, really, is an empty 200 response. It's the user's responsibility to make sure the configuration handles all possible requests with a handler that does what they want.

Regarding fail-fast on cert issues, the problem was that shutting down often triggers container restarts, causing Caddy to attempt issuance again, usually rapidly hitting rate limits. Caddy v2 no longer has this problem. I really can't imagine any situation where shutting down the server makes sense. Servers are kinda by-design supposed to be stable, and shutting down for any other reason than config/startup issues seems counterproductive. Do you have any specific usecase where it would be useful? You're the first to bring up this point since v2 was released.

Re: Caddy – Open-source web server with automatic HTTPS

#104

Post by philipwhiuk »

mholt wrote: post #94
nicolaslem wrote: post #92

Earlier quoted context omitted.

I don't know if the tone of the marketing is fixed. In the past I found the lack of humility surrounding the project off putting. Now I go to the website and the first thing I see is a giant "THE ULTIMATE SERVER", not a good start.

We're more confident about that one.

How can you be confident about it being the ultimate server when you say comparing performance can't be done.

Re: Caddy – Open-source web server with automatic HTTPS

#105

Post by philipwhiuk »

mholt wrote: post #26
PragmaticPulp wrote: post #21

Earlier quoted context omitted.

> I think the point is just that for most applications… I guess it would make more sense if they came right out and said that it’s best used for these applications where it’s acting as a reverse proxy for a heavy backend and therefore performance isn’t a big issue. But I’m constantly confused by the vague responses combined with the allusions to claims that it’s super-fast because it uses Go like Google or Tweets abo…

It's hard to quantify web server performance in a way that is both truly representative and truly generalizable, such that you can draw correct conclusions for specific setups and use cases. Ultimately we just recommend you do your own tuning and performance testing, especially since so many external factors are involved.

That would have been a better answer than "it performs as well as every other Go server" which probably does a dis-service to any tuning work you've done (or any tuning work any other server has done on the thin chance you've not done any).

Re: Caddy – Open-source web server with automatic HTTPS

#106

Post by genewitch »

mholt wrote: post #75
stronglikedan wrote: post #70

Earlier quoted context omitted.

> mholt is telling you It's not what he's saying, but how he's saying it. "I'm still waiting to hear your performance requirements btw.", is a condescending, dismissive tone that would put more people off than not. Especially considering it was a reply within just a couple minutes of his initial question.

Sorry, don't mean to be condescending or dismissive. Just trying to get stuff done. To do that, I'll need that information.

I've only used caddy twice, but it worked for like 2 years without interruption both times.

I don't think you're being negative or whatever and I also think the other person has an idea of what they want to know but not how to explain it.

Do they want connection handling metrics? SSL terminations? Caching performance?

Also, not at you but a general laugh, "the reverse proxy isn't the bottleneck ever" is funny because prior to haproxy, getting gigabit throughput to a backend was considered extreme engineering.

Now I can load balance and ssl terminate a gigabit with like 5 raspberry pi and an old Intel box to load balance and cache.

Re: Caddy – Open-source web server with automatic HTTPS

#107

Post by mholt »

philipwhiuk wrote: post #104
mholt wrote: post #94

Earlier quoted context omitted.

We're more confident about that one.

How can you be confident about it being the ultimate server when you say comparing performance can't be done.

There's a lot more to "ultimate" than just performance. It's a cross of many dimensions.

Re: Caddy – Open-source web server with automatic HTTPS

#108

Post by mcspiff »

FpUser wrote: post #93
francislavoie wrote: post #29

Earlier quoted context omitted.

You misunderstood then, because what was said was essentially "official benchmarks for servers are meaningless", not that "performance doesn't matter". Do your own testing, for your own usecase. But still, a server should rarely ever be your bottleneck. Your application's DB I/O will be.

>"But still, a server should rarely ever be your bottleneck. Your application's DB I/O will be." I have C++ server. Instead of constantly querying DB it holds all business data in RAM in appropriate structures optimized for real time usage, not how they're kept in DB. All read requests are basically limited by network IO except when some request calculates some more or less complex math. No waiting for DB. Writes are…

Not to diverge too much, but if you’re keeping everything in memory how do you handle hardware failures etc? Wouldn’t that result in data loss?

Re: Caddy – Open-source web server with automatic HTTPS

#109

Post by mholt »

francislavoie wrote: post #101
mook wrote: post #84

Earlier quoted context omitted.

I'd argue that HTTPS by default makes perfect sense for a _public facing_ server. For something on an internal network it doesn't make as much sense, especially since that makes using the default path for getting certificates difficult (can't get certs if you don't have DNS). I think what I'm trying to say is that Caddy was initially great for me (serving static files on the local network by IP address as an easy way…

FWIW, Caddy can act as its own CA, so it can issue certs for any private site, and you can add the root CA cert to any machines necessary. > but hasn't been that for ages Huh? It still is. This is all you need: :80 { root * /path/to/files file_server }

Or without a config file, simply:

    $ caddy file-server --root /path/to/files

Re: Caddy – Open-source web server with automatic HTTPS

#110

Post by FpUser »

mcspiff wrote: post #108
FpUser wrote: post #93

Earlier quoted context omitted.

>"But still, a server should rarely ever be your bottleneck. Your application's DB I/O will be." I have C++ server. Instead of constantly querying DB it holds all business data in RAM in appropriate structures optimized for real time usage, not how they're kept in DB. All read requests are basically limited by network IO except when some request calculates some more or less complex math. No waiting for DB. Writes are…

Not to diverge too much, but if you’re keeping everything in memory how do you handle hardware failures etc? Wouldn’t that result in data loss?

Data is written to disk but requests are batched and executed as a single transaction. It is very fast. Partner systems know that the request may fail and business processes are organized accordingly. In practice it never really happens. The overall performance is insane (hundreds of times better) comparatively to some Python scripts fishing in database for every request.
Post reply on HN