* Allow version to be set manually
When Caddy is built from a release tarball (as downloaded from GitHub),
`caddy version` returns an empty string. This causes confusion for
downstream packagers.
With this commit, VersionString can be set with eg.
go build (...) -ldflags '-X (...).VersionString=v1.2.3'
Then the short form version will be "v1.2.3", and the full version
string will begin with "v1.2.3 ".
* Prefer embedded version, then CustomVersion
* Prefer "unknown" for full version over empty
Co-authored-by: Matthew Holt <mholt@users.noreply.github.com>
* logging: Perform filtering on arrays of strings (where possible)
* Add test for ip_mask filter
* Oops, need to continue when it's not an IP
* Test for invalid IPs
This is something that has bothered me for a while, so I figured I'd do something about it now since I'm playing in the logging code lately.
The `console` encoder doesn't actually match the defaults that zap's default logger uses. This makes it match better with the rest of the logs when using the `console` encoder alongside somekind of filter, which requires you to configure an encoder to wrap.
Since all Windows services are run from the Windows system directory,
make it easier for users by switching to our program directory right
after the start.
PR #4066 added a dark color scheme to the file_server browse template.
PR #4356 later set the links for the `:visited` pseudo-class, but did
not set anything for the dark mode, resulting in poor contrast. I
selected some new colors by feel.
This commit also adds an `a:visited:hover` for both, to go along with
the normal blue hover colors.
It was not accurate. Placeholders could be used in outputs that are
defined in the same mapping as long as that placeholder does not do the
same.
A more general solution would be to detect it at run-time in the
replacer directly, but that's a bit tedious
and will require allocations I think.
A better implementation of this check could still be done, but I don't
know if it would always be accurate. Could be a "best-effort" thing?
But I've also never heard of an actual case where someone configured
infinite recursion...
Reported on commit e3e8aabbcf65d37516bb97f9dc0f77df52f8cf55
Abused this change in some bash for loops to rapidly reload config
while making requests and didn't observe any memory or resource leaks.
* core: Refactor, improve listener logic
Deprecate:
- caddy.Listen
- caddy.ListenTimeout
- caddy.ListenPacket
Prefer caddy.NetworkAddress.Listen() instead.
Change:
- caddy.ListenQUIC (hopefully to remove later)
- caddy.ListenerFunc signature (add context and ListenConfig)
- Don't emit Alt-Svc header advertising h3 over HTTP/3
- Use quic.ListenEarly instead of quic.ListenEarlyAddr; this gives us
more flexibility (e.g. possibility of HTTP/3 over UDS) but also
introduces a new issue:
https://github.com/lucas-clemente/quic-go/issues/3560#issuecomment-1258959608
- Unlink unix socket before and after use
* Appease the linter
* Keep ListenAll
e338648fed3263200dfd6abc9f8100c6f1c0eb67 introduced multiple upstream
addresses. A comment notes that mixing schemes isn't supported and
therefore the first valid scheme is supposed to be used.
Fixes setting the first scheme.
fixes#5087
* httpcaddyfile: Fix `protocols` global option parsing
When checking for a block, the current nesting must be used, otherwise it returns the wrong thing.
* Adjust adapt test to cover the broken behaviour that is now fixed
* Fix some admin tests which suddenly run even with -short
* caddyhttp: Honor grace period in background
This avoids blocking during config reloads.
* Don't quit process until servers shut down
* Make tests more likely to pass on fast CI (#5045)
* caddyhttp: Even faster shutdowns
Simultaneously shut down all HTTP servers, rather than one at a time.
In practice there usually won't be more than 1 that lingers. But this
code ensures that they all Shutdown() in their own goroutine
and then we wait for them at the end (if exiting).
We also wait for them to start up so we can be fairly confident the
shutdowns have begun; i.e. old servers no longer
accepting new connections.
* Fix comment typo
* Pull functions out of loop, for readability
Ideally I'd just remove the parameter to caddy.Context.Logger(), but
this would break most Caddy plugins.
Instead, I'm making it variadic and marking it as partially deprecated.
In the future, I might completely remove the parameter once most
plugins have updated.
