Thanks for the response! I'd imagined reasoning along those lines. I'd perhaps expect that people anticipating such high load that gzipping output is problematic would be investing enough time in server setup to review and tweak these options. And for everyone else, compression by default is a good starting point. Moving from Nginx (HTTP2 off by default) to Caddy (HTTP2 on by default) you'd already need to review your setup if running a highly trafficked site to ensure any reverse proxied servers can handle the additional request load due to multiplexing.
But it's obviously a trade-off and there's lots to weigh up...
Re:Caddyhttp: Enable HTTP/3 by Default
by tyingq on Thursday September 08, 2022 @05:21PM
(#32772252)
It is an interesting decision point, and I get your reasoning. But, I have noticed there are a good number of websites that could be better for their users (especially mobile users), because someone just took the defaults.
Not high priority, but if Caddy would offer a report of things that aren't configured but perhaps should be...that could help. Things like Cache-control/Expires/Etag headers, Gzip/Deflate, Caching, and so on.
Re:Caddyhttp: Enable HTTP/3 by Default
by layer8 on Thursday September 08, 2022 @04:34PM
(#32771720)
If gzip is enabled, is the gzipped version of a static file cached in memory, or is it gzipped anew for each request?
Caddy doesn't cache responses by default, but you can enable caching with the cache plugin: https://github.com/caddyserver/cache-handler/
Does this apply to static file serving? Although I suppose relying on the OS cache might be enough.
Re:Caddyhttp: Enable HTTP/3 by Default
by hsbauauvhabzb on Thursday September 08, 2022 @03:44PM
(#32771016)
Why was gzipping everything a facepalm? Performance?
Re:Caddyhttp: Enable HTTP/3 by Default
by francislavoie on Thursday September 08, 2022 @03:52PM
(#32771113)
It was making the browser download files with the .gz extension, instead of serving the content in a way that the browser would display. TL;DR it was broken at the time. But it was a very long time ago.
When I first announced Caddy in 2015 and the server got busy, it started downloading everything as .gz files. (facepalm) (good ol' days)
But that's just a fun story, not actually the reason we don't enable it by default...
The tricky thing about enabling features by default is that turning them off is awkward in config. And while we like to have "magic" in Caddy, we don't like too much magic. Plus, gzip performance in Go is less good (but more memory-safe) than it is in C and assembly. Klauspost's flate implementation is very fast and that's the one we use. But even with a super-fast implementation, gzip requires memory and CPU that busy servers may be in short supply of.
So it's opt-in for now. We can always change it later; going the other way is harder.
(Caddy also supports serving pre-compressed files, if enabled! And starting with Caddy 2.6, those can be teleported at the speed of electricity to HTTP clients using sendfile. HTTPS also sees faster file serving in 2.6 due to optimized copying.)
See also:
https://serverfault.com/questions/296770/why-arent-features-...