chore(deps): update dependency caddyserver/caddy to v2.6.2 #89
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "renovate/caddyserver-caddy-2.x"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This PR contains the following updates:
v2.5.2
->v2.6.2
Release Notes
caddyserver/caddy
v2.6.2
Compare Source
This release brings a number of bug fixes and minor enhancements. All users should upgrade after testing and verifying their setups. Thank you to all who contributed!
If you are coming from < 2.6, please see the 2.6 release notes because a lot is new!
Changelog
037dc23
admin: Use replacer on listen addresses (#5071)498f32b
caddyconfig: Implement retries into HTTPLoader (#5077)9873ff9
caddyhttp: Remote IP prefix placeholders61822f1
caddyhttp: replace placeholders in map defaults (#5081)e07a267
caddytest: Revise sleep durations253d97c
core: Chdir to executable location on Windows (#5115)ab720fb
core: Fix ListenQUIC listener key conflicte3e8aab
core: Refactor and improve listener logic (#5089)e4fac12
core: Set version manually via CustomVersion (#5072)f7c1a51
fastcgi: Redirect using original URI path (fix #5073)2be56c5
fileserver: Treat invalid file path as NotFound (#5099)b1d04f5
fileserver: better dark mode visited link contrast (#5105)33f60da
fileserver: stop listing dir when request context is cancelled (#5131)2153a81
forwardauth: Canonicalize header fields (fix #5038) (#5097)fe91de6
go.mod: Upgrade select dependencies7041970
headers: Support repeated WriteHeader if 1xx (fix #5074)d46ba2e
httpcaddyfile: Fixmetrics
global option parsing (#5126)6bad878
httpcaddyfile: Improve detection of indistinguishable TLS automation policies (#5120)2808de1
httpcaddyfile: Skipautomate
whenauto_https off
is specified (#5110)3e1fd2a
httpcaddyfile: Wrap site block in subroute if host matcher used (#5130)9e1d964
logging: Addtime_local
option to use local time instead of UTC (#5108)01e192e
logging: Betterconsole
encoder defaults (#5109)99ffe93
logging: Fixskip_hosts
with wildcards (#5102)ea58d51
logging: Perform filtering on arrays of strings (where possible) (#5101)5e52bbb
map: Remove infinite recursion check (#5094)b4e28af
replacer: working directory global placeholder (#5127)e2991eb
reverseproxy: On 103 don't delete own headers (#5091)2a8c458
reverseproxy: Parse humanized byte size (fix #5095)d055692
reverseproxy: fix upstream scheme handling in command (#5088)013b510
rewrite: Only trim prefix if matchedNew Contributors
Full Changelog: https://github.com/caddyserver/caddy/compare/v2.6.1...v2.6.2
v2.6.1
Compare Source
Hotfix for unix sockets, the
encode
handler, and thecaddy file-server
command. Please see the release notes for v2.6.0 for other important information if you're coming from < 2.6!Changelog
1426c97
core: Reuse unix sockets (UDS) and don't try to serve HTTP/3 over UDS (#5063)44ad0ce
encode: don't WriteHeader unless called (#5060)beb7dcb
fileserver: Reinstate --debug flagv2.6.0
Compare Source
Caddy 2.6
This is our biggest release since Caddy 2.
Caddy 2 changed the way the world serves the Web. By providing an online config API, automatic HTTPS, unlimited extensibility, certificate automation at scale, modern protocols, sane defaults, and an unrivaled developer experience, we boldly raised the bar for web servers.
Now with Caddy 2.6, we're doing it again. Caddy 2.6 is the first general-purpose web server to seamlessly enable the newly-standardized HTTP/3 protocol for all configurations by default. We've virtualized the file system so you can serve content from anywhere or anything. New event features let you observe and control Caddy's internals with custom actions. Caddy is more useful than ever for developers with its enhanced CLI tooling and features. And it's faster than ever with non-trivial performance improvements. We think you will love this release.
UPDATE: Please use v2.6.1 for hotfixes related to unix sockets,
encode
, andcaddy file-server
.Watch the livestream
Special dedication
This release is dedicated to the late Peter Eckersley, who passed away September 2, 2022. Peter is one of the brilliant minds behind Let's Encrypt; his work has benefited billions of people. I met Peter at the Let's Encrypt launch party in a little bar in San Francisco in 2015 and have never forgotten that occasion. He later co-authored a published research paper called Let’s Encrypt: An Automated Certificate Authority to Encrypt the Entire Web, which highly espoused Caddy's ACME integration: "We hope to see other popular server software follow Caddy’s lead."
We look forward to when other servers do that, and we hope to honor Peter's work and influence which will live on through his memory and the encrypted Web he made possible.
Sponsors
ZeroSSL remains Caddy's executive sponsor.
We were thrilled to welcome Stripe recently as an enterprise sponsor!
Other notable sponsors include AppCove, Dukaan, Suborbital, Tailscale, plus Bubble and GitHub which both made generous one-time donations.
We have many other vital sponsors and donors on which we also rely. Our sponsors come from all over the world and include independent professionals, startups, and small companies -- and they are the absolute best. Thank you for making a more secure Web possible!
Personal note from Matt: Recent life upgrades mean that your sponsorships now sustain a family of 5 so that I can continue to maintain Caddy. Two years ago, I don't think I would have taken this risk because I'd need to find other work to provide for a family. Thank you for coming together as a professional community to make the Caddy project possible!
We strongly recommend that companies who -- or companies whose customers -- use or benefit from Caddy become a sponsor to ensure ongoing maintenance, priority development, private support, and more. Sponsorship tiers can be tailored to your requirements!
Highlights
⚠️ Don't miss deprecations / breaking changes at the bottom. Notably, if you use metrics, you will now need to turn them on.
HTTP/3 is here (#4707)
Caddy now enables RFC 9114-compliant HTTP/3 by default. The
experimental_http3
option has graduated and been removed. We've removed another experimental option,allow_h2c
, and individual HTTP versions (h1 h2 h2c h3
) can now be toggled with the newprotocols
setting.Note that HTTP/3 utilizes the QUIC transport, which requires UDP. If your network or firewall configuration only allows TCP, HTTP/3 connections will fail and clients (should) fall back to HTTP/2. For servers with properly-configured UDP networks, HTTP/3 should "just work" for enabled clients.
HTTP/3 clients can connect by reading Caddy's Alt-Svc header to know how to connect to Caddy via UDP. This header is now emitted automatically and by default. Other than that, there are no other changes needed to existing servers, as Caddy opens a separate UDP socket for HTTP/3.
Our HTTP/3 server attempts to mitigate amplification and reflection attacks by requiring address validation when the server is under load. This adds one round-trip for clients, but is only done as a defensive measure when necessary.
Serious thanks to @marten-seemann who builds and maintains the quic-go library we depend on for this. (Go has not announced any plans to officially support or implement HTTP/3.) We expect numerous QUIC and HTTP/3 improvements to come as implementations and best practices mature with more production experience.
Virtual file systems (#4909)
Caddy's
file_server
module now supports virtual file systems. We've replaced all hard-codedos.Open()
,os.Stat()
, etc. calls with Go's relatively newio/fs
package, and introduced a new Caddy module namespacecaddy.fs
for implementations of such file systems.Some examples of what is possible:
caddy
binary and serve it from memory.zip
or.tar.gz
)Basically, instead of serving files from the local disk, you can have Caddy serve the "files" from somewhere or something else. The default is still the local file system.
Note that this feature isn't limited to just Caddy's
file_server
module. Potentially any module that reads the local disk may benefit from usingcaddy.fs
modules instead.I wrote a module that lets you embed your site within your
caddy
binary -- wherever your server goes, your site goes!We encourage the community to implement and publish new file system modules for Caddy. (From an early tweet there seems to be quite high demand.)
Events (#4912 and #4984)
Not surprisingly, many people prefer Caddy to automate certificates used with other software/services. Until now, there hasn't been a great way to know when Caddy has obtained or renewed a certificate (deferred in part by our opinion that certificate management should be baked into the software using the certificate in the first place). Cron jobs generally work for reloading new certificates into services because certificate expiry is mostly predictable, but now there is a better way with one of our most requested features: events!
We thought about events in general for a long time and discussed questions like, "What makes an event different from a log?" "Are events synchronous?" "Do self-initiated events get emitted before or after their code (are they past-tense or future-tense) -- or both? or neither (asynchronous)?" "What do we like from existing event systems?" "What do we wish event systems did differently?"
While we think we have pretty good answers to these questions now, we won't be sure until we gather more production experience. For this reason, events are implemented as an experimental app module -- not as part of the core. (Remember, Caddy's core currently only loads config and sets up logging/storage.) This means that Caddy's core cannot emit events.[^1] So even though our event implementation may change, it is likely to be only slight and gradual changes; and we encourage anyone and everyone to start using events as soon as possible and to give us your feedback. We think we have the start of a great event system, but we need you to prove it!
Caddy modules can emit events when interesting things happen. For example, the reverse proxy emits
healthy
andunhealthy
events when backends go up and down. The TLS app emitscert_obtaining
,cert_obtained
, andcert_failed
before and after obtaining a certificate or after the operation failed, respectively; andcert_ocsp_revoked
after a certificate is discovered to be revoked by OCSP. There are several more events already, with even more to be added later.Events can have data associated with them. For example,
healthy
/unhealthy
come with the address of the host;cert_obtained
has the domain name, issuer, and storage path. You can access this from config in placeholders, e.g.{event.data.identifier}
.Caddy modules can subscribe to events by specifying the name(s) of events to bind to, and the Caddy module ID(s) or namespace(s) to watch. When an event is emitted, it propagates from the module that emitted it up the provisioning heirarchy. This means that an event emitted by
http.handlers.reverse_proxy
will fire forhttp.handlers
andhttp
as well, similar to the DOM in HTML/JavaScript.Event handlers are invoked synchronously. We chose this for several reasons. First, despite how easy Go makes concurrency, there are many subtleties to concurrency in a server. Goroutines may be lightweight, but their operations might not be; and if event goroutines are starting more quickly than they are stopping, we either drop events arbitrarily or run out of memory/CPU. Also, we think one of the qualities that differentiates events from logs is the ability for an event to influence the emitting code's flow: a true "hook" in that sense. Instead of simply observing that something is happening (which is what a log tells you), you can influence its behavior. Maybe you want to run a command before a certificate is obtained to see if it should be obtained. Or maybe you want to change how a TLS handshake is completed on-the-fly. Asynchronous event handlers cannot do this. For simple behavioral changes, synchronous events can be a powerful and useful tool for customizing your server.
The new
event
app lets you easily configure subscriptions and event handlers. Event handling is modular, so you will need to plug in a module that does what you want: run a command, reload a service, make an HTTP request, or anything else!Because this feature is experimental and new, we don't yet know how people will be using it, so currently, Caddy does not ship with any event handler plugins. However, we're pretty sure based on feedback over the years that many of you would like to run commands on certain events (one of our top feature requests is to trigger a daemon reload after certificate renewals). So I went ahead and implemented an
exec
event handler plugin that can run commands. We almost included it in Caddy's standard distribution, but out of an abundance of caution we decided to keep it a separate plugin for now until we learn more about real production use cases from experience.Here's an example of handling events. In JSON, you configure the
events
app:or the equivalent Caddyfile global option:
It's that simple! Just make sure you have your event handler modules plugged in.
We hope you will provide feedback, report bugs, and request features related to events.
f777877e26
to9ab1e05cb6
chore(deps): update dependency caddyserver/caddy to v2.6.0to chore(deps): update dependency caddyserver/caddy to v2.6.19ab1e05cb6
to318fd226ed
chore(deps): update dependency caddyserver/caddy to v2.6.1to chore(deps): update dependency caddyserver/caddy to v2.6.2