Huge thank-you to Tailscale (https://tailscale.com) for making this change possible!
This is a great feature for Caddy and Tailscale is a great fit for a standard implementation.
* caddytls: GetCertificate modules; Tailscale
* Caddyfile support for get_certificate
Also fix AP provisioning in case of empty subject list (persist loaded
module on struct, much like Issuers, to surive reprovisioning).
And implement start of HTTP cert getter, still WIP.
* Update modules/caddytls/automation.go
Co-authored-by: Francis Lavoie <lavofr@gmail.com>
* Use tsclient package, check status for name
* Implement HTTP cert getter
And use reuse CertMagic's PEM functions for private keys.
* Remove cache option from Tailscale getter
Tailscale does its own caching and we don't need the added complexity...
for now, at least.
* Several updates
- Option to disable cert automation in auto HTTPS
- Support multiple cert managers
- Remove cache feature from cert manager modules
- Minor improvements to auto HTTPS logging
* Run go mod tidy
* Try to get certificates from Tailscale implicitly
Only for domains ending in .ts.net.
I think this is really cool!
Co-authored-by: Francis Lavoie <lavofr@gmail.com>
The `net.JoinHostPort()` function has some naiive logic for handling IPv6, it just checks if the host part has a `:` and if so it wraps the host part with `[ ]` but this causes our network type prefix to get wrapped as well, which is invalid for `caddy.NetworkAddress`. Instead, we can just concatenate the host and port manually here to avoid this side-effect.
We realized we made some mistakes with the directive ordering, so we're making some minor adjustments.
`abort` and `error` don't really make sense to be after other handler directives, because you would expect to be able to "fail-fast" and throw an error before falling through to some `file_server` or `respond` typically. So we're moving them up to just before `respond`, i.e. before the common handler directives.
This is also more consistent with our existing examples in the docs, which actually didn't work due to the directive ordering. See https://caddyserver.com/docs/caddyfile/directives/error#examples
Also, `push` doesn't quite make sense to be after `handle`/`route`, since its job is to read from response headers to push additional resources if necessary, and `handle`/`route` may be terminal so push would not be reached if it was declared outside those. And also, it would make sense to be _before_ `templates` because a template _could_ add a `Link` header to the response dynamically.
Some new users mistakenly try to define two sites without braces around each. Doing this can yield a confusing error message saying that their site address is an "unknown directive".
We can do better by keeping track of whether the current site block was parsed with or without a brace, then changing the error message later based on that.
For example, now this invalid config:
```
foo.example.com
respond "foo"
bar.example.com
respond "bar"
```
Will yield this error message:
```
$ caddy adapt
2021/08/22 19:21:31.028 INFO using adjacent Caddyfile
adapt: Caddyfile:4: unrecognized directive: bar.example.com
Did you mean to define a second site? If so, you must use curly braces around each site to separate their configurations.
```
Some users forget to use a comma between their site addresses. This is invalid (commas aren't a valid character in domains) and later parts of the code like certificate automation will try to use this otherwise, which doesn't make sense. Best to error as early as possible.
Example thread on the forums where this happened: https://caddy.community/t/simplify-caddyfile/13281/9
* httpcaddyfile: Add shortcut for proxy hostport placeholder
I've noticed that it's a pretty common pattern to write a proxy like this, when needing to proxy over HTTPS:
```
reverse_proxy https://example.com {
header_up Host {http.reverse_proxy.upstream.hostport}
}
```
I find it pretty hard to remember the exact placeholder to use for this, and I continually need to refer to the docs when I need it. I think a simple fix for this is to add another Caddyfile placeholder for this one to shorten it:
```
reverse_proxy https://example.com {
header_up Host {proxy_hostport}
}
```
* Switch the shortcut name
* httpcaddyfile: ensure hosts to skip can always be collected
Previously, some hosts that should be skipped in logging would
be missed as the current logic would only collect them after
encountering the first server that would log. This change makes sure
the ServerLogConfig is initialized before iterating over the server
blocks.
* httpcaddyfile: add test case for skip hosts behavior
If an email is specified in global options, a site called 'localhost' shouldn't be bunched together with public DNS names in the automation policies, which get the default, public-CA issuers. Fix old test that did this.
I also noticed that these two:
localhost {
}
example.com {
}
and
localhost, example.com {
}
produce slightly different TLS automation policies. The former is what the new test case covers, and we have logic that removes the empty automation policy for localhost so that auto-HTTPS can implicitly create one. (We prefer that whenever possible.) But the latter case produces two automation policies, with the second one being for localhost, with an explicit internal issuer. It's not wrong, just more explicit than it needs to be.
I'd really like to completely rewrite the code from scratch that generates automation policies, hopefully there is a simpler, more correct algorithm.
In the Caddyfile, hosts specified for HTTP sockets (either scheme is "http" or it is on the HTTP port) should not be used as subjects in TLS automation policies (APs).
* caddyfile: Add parse error on site address in `{`
This is an incredibly common mistake made by users, so we should catch it earlier in the parser and give a more friendly message. Often it ends up adapting but with mistakes, or erroring out later due to other site addresses being read as directives.
There's not really ever a situation where a lone '{' is valid at the end of a site address (but I suppose there are edgecases where the user wants to use a path matcher where it ends specifically in `{`, but... why?), so this should be fine.
* Update caddyconfig/caddyfile/parse.go
* caddyfile(formatter): fix nesting not decrementing
This is an extremely weird edge-case where if you had a environment variable {}
on one line, a comment on the next line, and the closing of the block on the
following line; the rest of the Caddyfile would be indented further than it
should've been.
ref; https://github.com/matthewpi/vscode-caddyfile-support/issues/13
* run gofmt
* fmt: better way of handling edge case
* reverseproxy: Add `handle_response` blocks to `reverse_proxy` (#3710)
* reverseproxy: complete handle_response test
* reverseproxy: Change handle_response matchers to use named matchers
reverseproxy: Add support for changing status code
* fastcgi: Remove obsolete TODO
We already have d.Err("transport already specified") in the reverse_proxy parsing code which covers this case
* reverseproxy: Fix support for "4xx" type status codes
* Apply suggestions from code review
Co-authored-by: Matt Holt <mholt@users.noreply.github.com>
* caddyhttp: Reorganize response matchers
* reverseproxy: Reintroduce caddyfile.Unmarshaler
* reverseproxy: Add comment mentioning Finalize should be called
Co-authored-by: Maxime Soulé <btik-git@scoubidou.com>
Co-authored-by: Matt Holt <mholt@users.noreply.github.com>
* httpcaddyfile: Fix unexpectedly removed policy
When user set on_demand tls option in a catch-all (:443) policy,
we expect other policies to not have the on_demand enabled
See ex in tls_automation_policies_5.txt
Btw, we can remove policies if they are **all** empty.
* Update caddyconfig/httpcaddyfile/tlsapp.go
Co-authored-by: Matt Holt <mholt@users.noreply.github.com>
Co-authored-by: Matt Holt <mholt@users.noreply.github.com>
* caddyfile: Fix `import` replacing unrelated placeholders
See https://caddy.community/t/snippet-issue-works-outside-snippet/12231
So it turns out that `NewReplacer()` gives a replacer with some global defaults (like `{env.*}` and some system and time placeholders), which is not ideal when running `import` because we just want to replace `{args.*}` only, and nothing else.
* caddyfile: Add test
* caddyfile: reject recursive self-imports
* caddyfile: detect and reject cyclic imports of snippets and files
* caddyfile: do not be stickler about connected nodes not being connected already
* caddyfile: include missing test artifacts of cyclic imports
* address review comments
This change is aimed at enhancing the logging module within the
Caddyfile directive to allow users to configure logs other than the HTTP
access log stream, which is the current capability of the Caddyfile [1].
The intent here is to leverage the same syntax as the server log
directive at a global level, so that similar customizations can be added
without needing to resort to a JSON-based configuration.
Discussion for this approach happened in the referenced issue.
Closes https://github.com/caddyserver/caddy/issues/3958
[1] https://caddyserver.com/docs/caddyfile/directives/log
Allows conveniently setting the resolvers for the DNS challenge using a TLS subdirective, which applies to default issuers, rather than having to explicitly define the issuers and overwrite the defaults.
The HTTP Caddyfile adapter can now configure the PKI app, and the acme_server directive can now be used to specify a custom CA used for issuing certificates. More customization options can follow later as needed.
If `tls <email>` is used, we should apply that to all applicable default issuers, not drop them. This refactoring applies implicit ACME issuer settings from the tls directive to all default ACME issuers, like ZeroSSL.
We also consolidate some annoying logic and improve config validity checks.
Ref: https://caddy.community/t/error-obtaining-certificate-after-caddy-restart/11335/8
* caddyhttp: Implement handler abort; new 'abort' directive (close#3871)
* Move abort directive ordering; clean up redirects
Seems logical for the end-all of handlers to go at the... end.
The Connection header no longer needs to be set there, since Close is
true, and the static_response handler now does that.
This commits dds 3 separate, but very related features:
1. Automated server identity management
How do you know you're connecting to the server you think you are? How do you know the server connecting to you is the server instance you think it is? Mutually-authenticated TLS (mTLS) answers both of these questions. Using TLS to authenticate requires a public/private key pair (and the peer must trust the certificate you present to it).
Fortunately, Caddy is really good at managing certificates by now. We tap into that power to make it possible for Caddy to obtain and renew its own identity credentials, or in other words, a certificate that can be used for both server verification when clients connect to it, and client verification when it connects to other servers. Its associated private key is essentially its identity, and TLS takes care of possession proofs.
This configuration is simply a list of identifiers and an optional list of custom certificate issuers. Identifiers are things like IP addresses or DNS names that can be used to access the Caddy instance. The default issuers are ZeroSSL and Let's Encrypt, but these are public CAs, so they won't issue certs for private identifiers. Caddy will simply manage credentials for these, which other parts of Caddy can use, for example: remote administration or dynamic config loading (described below).
2. Remote administration over secure connection
This feature adds generic remote admin functionality that is safe to expose on a public interface.
- The "remote" (or "secure") endpoint is optional. It does not affect the standard/local/plaintext endpoint.
- It's the same as the [API endpoint on localhost:2019](https://caddyserver.com/docs/api), but over TLS.
- TLS cannot be disabled on this endpoint.
- TLS mutual auth is required, and cannot be disabled.
- The server's certificate _must_ be obtained and renewed via automated means, such as ACME. It cannot be manually loaded.
- The TLS server takes care of verifying the client.
- The admin handler takes care of application-layer permissions (methods and paths that each client is allowed to use).\
- Sensible defaults are still WIP.
- Config fields subject to change/renaming.
3. Dyanmic config loading at startup
Since this feature was planned in tandem with remote admin, and depends on its changes, I am combining them into one PR.
Dynamic config loading is where you tell Caddy how to load its config, and then it loads and runs that. First, it will load the config you give it (and persist that so it can be optionally resumed later). Then, it will try pulling its _actual_ config using the module you've specified (dynamically loaded configs are _not_ persisted to storage, since resuming them doesn't make sense).
This PR comes with a standard config loader module called `caddy.config_loaders.http`.
Caddyfile config for all of this can probably be added later.
COMMITS:
* admin: Secure socket for remote management
Functional, but still WIP.
Optional secure socket for the admin endpoint is designed
for remote management, i.e. to be exposed on a public
port. It enforces TLS mutual authentication which cannot
be disabled. The default port for this is :2021. The server
certificate cannot be specified manually, it MUST be
obtained from a certificate issuer (i.e. ACME).
More polish and sensible defaults are still in development.
Also cleaned up and consolidated the code related to
quitting the process.
* Happy lint
* Implement dynamic config loading; HTTP config loader module
This allows Caddy to load a dynamic config when it starts.
Dynamically-loaded configs are intentionally not persisted to storage.
Includes an implementation of the standard config loader, HTTPLoader.
Can be used to download configs over HTTP(S).
* Refactor and cleanup; prevent recursive config pulls
Identity management is now separated from remote administration.
There is no need to enable remote administration if all you want is identity
management, but you will need to configure identity management
if you want remote administration.
* Fix lint warnings
* Rename identities->identifiers for consistency
Previous commit improved the Caddyfile adapter so it doesn't unnecessarily add names to "skip" in "auto_https" when the server is already HTTP-only.
This commit updates the tests to reflect that change, while also fixing the Caddyfile formatting in many of the tests.
We also print the line number of the divergence between input and formatted version in Caddyfile adapt warnings - very useful for finding initial formatting problems.
This is probably an invasive change, but existing tests continue to pass.
It seems to make sense this way. There is likely an edge case I haven't
considered.
Allows user to disable OCSP stapling (including support in the Caddyfile via the ocsp_stapling global option) or overriding responder URLs. Useful in environments where responders are not reachable due to firewalls.
This changes the signature of UnmarshalGlobalFunc but this is probably OK since it's only used by this repo as far as we know.
We need this change in order to "remember" the previous value in case a global option appears more than once, which is now a possibility with the cert_issuer option since Caddy now supports multiple issuers in the order defined by the user.
Bonus: the issuer subdirective of tls now supports one-liner for "acme" when all you need to set is the directory:
issuer acme <dir>
* caddyfile: Introduce basic linting and fmt check
This will help encourage people to keep their Caddyfiles tidy.
* Remove unrelated tests
I am not sure that testing the output of warnings here is quite the
right idea; these tests are just for syntax and parsing success.
* httpcaddyfile: First pass at implementing server options
* httpcaddyfile: Add listener wrapper support
* httpcaddyfile: Sort sbaddrs to make adapt output more deterministic
* httpcaddyfile: Add server options adapt tests
* httpcaddyfile: Windows line endings lol
* caddytest: More windows line endings lol (sorry Matt)
* Update caddyconfig/httpcaddyfile/serveroptions.go
Co-authored-by: Matt Holt <mholt@users.noreply.github.com>
* httpcaddyfile: Reword listener address "matcher"
* Apply suggestions from code review
Co-authored-by: Matt Holt <mholt@users.noreply.github.com>
* httpcaddyfile: Deprecate experimental_http3 option (moved to servers)
* httpcaddyfile: Remove validation step, no longer needed
Co-authored-by: Matt Holt <mholt@users.noreply.github.com>
* ci: Use golangci's github action for linting
Signed-off-by: Dave Henderson <dhenderson@gmail.com>
* Fix most of the staticcheck lint errors
Signed-off-by: Dave Henderson <dhenderson@gmail.com>
* Fix the prealloc lint errors
Signed-off-by: Dave Henderson <dhenderson@gmail.com>
* Fix the misspell lint errors
Signed-off-by: Dave Henderson <dhenderson@gmail.com>
* Fix the varcheck lint errors
Signed-off-by: Dave Henderson <dhenderson@gmail.com>
* Fix the errcheck lint errors
Signed-off-by: Dave Henderson <dhenderson@gmail.com>
* Fix the bodyclose lint errors
Signed-off-by: Dave Henderson <dhenderson@gmail.com>
* Fix the deadcode lint errors
Signed-off-by: Dave Henderson <dhenderson@gmail.com>
* Fix the unused lint errors
Signed-off-by: Dave Henderson <dhenderson@gmail.com>
* Fix the gosec lint errors
Signed-off-by: Dave Henderson <dhenderson@gmail.com>
* Fix the gosimple lint errors
Signed-off-by: Dave Henderson <dhenderson@gmail.com>
* Fix the ineffassign lint errors
Signed-off-by: Dave Henderson <dhenderson@gmail.com>
* Fix the staticcheck lint errors
Signed-off-by: Dave Henderson <dhenderson@gmail.com>
* Revert the misspell change, use a neutral English
Signed-off-by: Dave Henderson <dhenderson@gmail.com>
* Remove broken golangci-lint CI job
Signed-off-by: Dave Henderson <dhenderson@gmail.com>
* Re-add errantly-removed weakrand initialization
Signed-off-by: Dave Henderson <dhenderson@gmail.com>
* don't break the loop and return
* Removing extra handling for null rootKey
* unignore RegisterModule/RegisterAdapter
Co-authored-by: Mohammed Al Sahaf <msaa1990@gmail.com>
* single-line log message
Co-authored-by: Matt Holt <mholt@users.noreply.github.com>
* Fix lint after a1808b0dbf209c615e438a496d257ce5e3acdce2 was merged
Signed-off-by: Dave Henderson <dhenderson@gmail.com>
* Revert ticker change, ignore it instead
Signed-off-by: Dave Henderson <dhenderson@gmail.com>
* Ignore some of the write errors
Signed-off-by: Dave Henderson <dhenderson@gmail.com>
* Remove blank line
Signed-off-by: Dave Henderson <dhenderson@gmail.com>
* Use lifetime
Signed-off-by: Dave Henderson <dhenderson@gmail.com>
* close immediately
Co-authored-by: Matt Holt <mholt@users.noreply.github.com>
* Preallocate configVals
Signed-off-by: Dave Henderson <dhenderson@gmail.com>
* Update modules/caddytls/distributedstek/distributedstek.go
Co-authored-by: Mohammed Al Sahaf <msaa1990@gmail.com>
Co-authored-by: Matt Holt <mholt@users.noreply.github.com>
* implement default values for header directive
closes#3804
* remove `set_default` header op and rely on "require" handler instead
This has the following advantages over the previous attempt:
- It does not introduce a new operation for headers, but rather nicely
extends over an existing feature in the header handler.
- It removes the need to specify the header as "deferred" because it is
already implicitely deferred by the use of the require handler. This
should be less confusing to the user.
* add integration test for header directive in caddyfile
* bubble up errors when parsing caddyfile header directive
* don't export unnecessarily and don't canonicalize headers unnecessarily
* fix response headers not passed in blocks
* caddyfile: fix clash when using default header in block
Each header is now set in a separate handler so that it doesn't clash
with other headers set/added/deleted in the same block.
* caddyhttp: New idle_timeout default of 5m
* reverseproxy: fix random hangs on http/2 requests with server push (#3875)
see https://github.com/golang/go/issues/42534
* Refactor and cleanup with improvements
* More specific link
Co-authored-by: Matthew Holt <mholt@users.noreply.github.com>
Co-authored-by: Денис Телюх <telyukh.denis@gmail.com>
* caddytls: Support multiple issuers
Defaults are Let's Encrypt and ZeroSSL.
There are probably bugs.
* Commit updated integration tests, d'oh
* Update go.mod
* httpcaddyfile: Revise automation policy generation
This should fix a frustrating edge case where wildcard subjects are
used, which potentially get shadowed by more specific versions of
themselves; see the new tests for an example. This change is motivated
by an actual customer requirement.
Although all the tests pass, this logic is incredibly complex and
nuanced, and I'm worried it is not correct. But it took me about 4 days
to get this far on a solution. I did my best.
* Fix typo
We have users that have site blocks like *.*.tld with on-demand TLS
enabled. While *.*.tld does not qualify for a publicly-trusted cert due
to its wildcards, On-Demand TLS does not actually obtain a cert with
those wildcards, since it uses the actual hostname on the handshake.
This improves on that logic, but I am still not 100% satisfied with the
result since I think we need to also check if another site block is more
specific, like foo.example.tld, which might not have on-demand TLS
enabled, and make sure an automation policy gets created before the
more general policy with on-demand...
* httpcaddyfile: Ensure handle_path is sorted as equal to handle
* httpcaddyfile: Make mutual exclusivity grouping deterministic (I hope)
* httpcaddyfile: Add comment linking to the issue being fixed
* httpcaddyfile: Typo fix, comment clarity
Co-authored-by: Matt Holt <mholt@users.noreply.github.com>
* Update caddyconfig/httpcaddyfile/httptype.go
Co-authored-by: Matt Holt <mholt@users.noreply.github.com>
We recently introduced `if !cp.SettingsEmpty()` which conditionally
adds the connection policy to the list. If the condition evaluates to
false, the policy wouldn't actually be added, even if
hasCatchAllTLSConnPolicy was set to true on the previous line.
Now we set that variable in accordance with whether we actually add
the policy.
While debugging this I noticed that catch-all policies added early in
that loop (i.e. not at the end if we later determine we need one) are
not always at the end of the list. They should be, though, since they
are selected by which one matches first, and having a catch-all first
would nullify any more specific ones later in the list. So I added a
sort in consolidateConnPolicies to take care of that.
Should fix#3670 and
https://caddy.community/t/combining-on-demand-tls-with-custom-ssl-certs-doesnt-seem-to-work-in-2-1-1/9719
but I won't know for sure until somebody verifies it, since at least in
the GitHub issue there is not yet enough information (the configs are
redacted).
* httpcaddyfile: Flip `root` directive sort order
* httpcaddyfile: Sort directives with any matcher before those with none
* httpcaddyfile: Generalize reverse sort directives, improve logic
* httpcaddyfile: Fix "spelling" issue
* httpcaddyfile: Turns out the second change precludes the first
httpcaddyfile: Delete test that no longer makes sense
* httpcaddyfile: Shorten logic
Co-authored-by: Matt Holt <mholt@users.noreply.github.com>
Co-authored-by: Matt Holt <mholt@users.noreply.github.com>
* caddytls: Add support for ZeroSSL; add Caddyfile support for issuers
Configuring issuers explicitly in a Caddyfile is not easily compatible
with existing ACME-specific parameters such as email or acme_ca which
infer the kind of issuer it creates (this is complicated now because
the ZeroSSL issuer wraps the ACME issuer)... oh well, we can revisit
that later if we need to.
New Caddyfile global option:
{
cert_issuer <name> ...
}
Or, alternatively, as a tls subdirective:
tls {
issuer <name> ...
}
For example, to use ZeroSSL with an API key:
{
cert_issuser zerossl API_KEY
}
For now, that still uses ZeroSSL's ACME endpoint; it fetches EAB
credentials for you. You can also provide the EAB credentials directly
just like any other ACME endpoint:
{
cert_issuer acme {
eab KEY_ID MAC_KEY
}
}
All these examples use the new global option (or tls subdirective). You
can still use traditional/existing options with ZeroSSL, since it's
just another ACME endpoint:
{
acme_ca https://acme.zerossl.com/v2/DV90
acme_eab KEY_ID MAC_KEY
}
That's all there is to it. You just can't mix-and-match acme_* options
with cert_issuer, because it becomes confusing/ambiguous/complicated to
merge the settings.
* Fix broken test
This test was asserting buggy behavior, oops - glad this branch both
discovers and fixes the bug at the same time!
* Fix broken test (post-merge)
* Update modules/caddytls/acmeissuer.go
Fix godoc comment
Co-authored-by: Francis Lavoie <lavofr@gmail.com>
* Add support for ZeroSSL's EAB-by-email endpoint
Also transform the ACMEIssuer into ZeroSSLIssuer implicitly if set to
the ZeroSSL endpoint without EAB (the ZeroSSLIssuer is needed to
generate EAB if not already provided); this is now possible with either
an API key or an email address.
* go.mod: Use latest certmagic, acmez, and x/net
* Wrap underlying logic rather than repeating it
Oops, duh
* Form-encode email info into request body for EAB endpoint
Co-authored-by: Francis Lavoie <lavofr@gmail.com>
* Bring `ensure_origin` and `origins` to caddyfile admin config
* Add unit test for caddyfile admin config update
* Add caddyfile adapt test for typical admin setup
* httpcaddyfile: Replace admin config error message when there's more arguments than needed
Replace d.Err() to d.ArgErr() since the latter provides similarly informative error message
Co-authored-by: Matt Holt <mholt@users.noreply.github.com>
Co-authored-by: Matt Holt <mholt@users.noreply.github.com>
* push: Implement HTTP/2 server push (close#3551)
* push: Abstract header ops by embedding into new struct type
This will allow us to add more fields to customize headers in
push-specific ways in the future.
* push: Ensure Link resources are pushed before response is written
* Change header name from X-Caddy-Push to Caddy-Push
Catch-alls should always go last. Normally this is the case, but we have
a special case for comparing one wildcard-host site block to another
non-wildcard host site block; and a catch-all site block is also a
non-wildcard host site block, so now we have to special-case the
catch-all site block. Sigh.
This could be reproduced with a Caddyfile that has two site blocks:
":80" and "*.example.com", in that order.
* Adds global options for external account bindings
* Maybe other people use ctags too?
* Use nested block to configure external account
* go format files
* Restore acme_ca directive in test file
* Change Caddyfile config syntax for acme_eab
* Update test
Co-authored-by: Matt Holt <mholt@users.noreply.github.com>
* caddyconfig: WIP implementation of handle_path
* caddyconfig: Complete the implementation - h.NewRoute was key
* caddyconfig: Add handle_path integration test
* caddyhttp: Use the path matcher as-is, strip the trailing *, update test
* httpcaddyfile: Add shorthands for parameterized placeholders
httpcaddyfile: Now with regexp instead
httpcaddyfile: Allow dashes, gofmt
httpcaddyfile: Compile regexp only once
httpcaddyfile: Cleanup struct
httpcaddyfile: Optimize the replacers, pull out of the loop
httpcaddyfile: Add `{port}` shorthand
* httpcaddyfile: Switch `r.` to `re.`
* caddy: Add support for `d` duration unit
* Improvements to ParseDuration; add unit tests
Co-authored-by: Matthew Holt <mholt@users.noreply.github.com>
* httpcaddyfile: Make global options pluggable
* httpcaddyfile: Add a global options adapt test
* httpcaddyfile: Wrap err
Co-Authored-By: Dave Henderson <dhenderson@gmail.com>
* httpcaddyfile: Revert wrap err
Co-authored-by: Dave Henderson <dhenderson@gmail.com>
https://caddy.community/t/cant-get-simple-alias-to-work/7911/8?u=matt
This removes an optimization where we amortized path matcher decoding.
The decoded matchers were index by... position... which obviously
changes during sorting. Duh.
Anyway, sorting is sliiightly slower now but the Caddyfile is not
really CPU-sensitive, so this is fine.
This can lead to nicer, smaller JSON output for Caddyfiles like this:
a {
tls internal
}
b {
tls foo@bar.com
}
i.e. where the tls directive only configures automation policies, and
is merely meant to enable TLS on a server block (if it wasn't implied).
This helps keeps implicit config implicit.
Needs a little more testing to ensure it doesn't break anything
important.
* httpcaddyfile: Exclude access logs written to files from default log
Even though any logs can just be ignored, most users don't seem to like
configuring an access log to go to a file only to have it doubly appear
in the default log.
Related to:
- #3294
- https://caddy.community/t/v2-logging-format/7642/4?u=matt
- https://caddy.community/t/caddyfile-questions/7651/3?u=matt
* caddyhttp: General improvements to access log controls (fixes#3310)
* caddyhttp: Move log config nil check higher
* Rename LoggerName -> DefaultLoggerName
Panic would happen if an automation policy was specified in a singular
server block that had no hostnames in its address. Definitely an edge
case.
Fixed a bug related to checking for server blocks with a host-less key
that tried to make an automation policy. Previously if you had only two
server blocks like ":443" and another one at ":80", the one at ":443"
could not create a TLS automation policy because it thought it would
interfere with TLS automation for the block at ":80", but obviously that
key doesn't enable TLS because it is on the HTTP port. So now we are a
little smarter and count only non-HTTP-empty-hostname keys.
Also fixed a bug so that a key like "https://:1234" is sure to have TLS
enabled by giving it a TLS connection policy. (Relaxed conditions
slightly; the previous conditions were too strict, requiring there to be
a TLS conn policy already or a default SNI to be non-empty.)
Also clarified a comment thanks to feedback from @Mohammed90
These functions are called at init-time, and their inputs are hard-coded
so there are no environmental or user factors that could make it fail
or succeed; the error return values are often ignored, and when they're
not, they are usually a fatal error anyway. To ensure that a programmer
mistake is not missed, we now panic instead.
Last breaking change 🤞
- Create two default automation policies; if the TLS app is used in
isolation with the 'automate' certificate loader, it will now use
an internal issuer for internal-only names, and an ACME issuer for
all other names by default.
- If the HTTP Caddyfile adds an 'automate' loader, it now also adds an
automation policy for any names in that loader that do not qualify
for public certificates so that they will be issued internally. (It
might be nice if this wasn't necessary, but the alternative is to
either make auto-HTTPS logic way more complex by scanning the names in
the 'automate' loader, or to have an automation policy without an
issuer switch between default issuer based on the name being issued
a certificate - I think I like the latter option better, right now we
do something kind of like that but at a level above each individual
automation policies, we do that switch only when no automation
policies match, rather than when a policy without an issuer does
match.)
- Set the default LoggerName rather than a LoggerNames with an empty
host value, which is now taken literally rather than as a catch-all.
- hostsFromKeys, the function that gets a list of hosts from server
block keys, no longer returns an empty string in its resulting slice,
ever.
We now store the parsed site/server block keys with the server block,
rather than parsing the addresses every time we read them.
Also detect conflicting schemes, i.e. TLS and non-TLS cannot be served
from the same server (natively -- modules could be built for it).
Also do not add site subroutes (subroutes generated specifically from
site blocks in the Caddyfile) that are empty.
Thus far the fuzzers have found a few crashers in the Caddyfile parser. However, the fuzzer have been stuck at import glob expansion after import glob expansion, which aren't reproducible.
Certificate selection used to be a module, but this seems unnecessary,
especially since the built-in CustomSelectionPolicy allows quite complex
selection logic on a number of fields in certs. If we need to extend
that logic, we can, but I don't think there are SO many possibilities
that we need modules.
This update also allows certificate selection to choose between multiple
matching certs based on client compatibility and makes a number of other
improvements in the default cert selection logic, both here and in the
latest CertMagic.
The hardest part of this was the conn policy consolidation logic
(Caddyfile only, of course). We have to merge connection policies that
we can easily combine, because if two certs are manually loaded in a
Caddyfile site block, that produces two connection policies, and each
cert is tagged with a different tag, meaning only the first would ever
be selected. So given the same matchers, we can merge the two, but this
required improving the Tag selection logic to support multiple tags to
choose from, hence "tags" changed to "any_tag" or "all_tags" (but we
use any_tag in our Caddyfile logic).
Combining conn policies with conflicting settings is impossible, so
that should return an error if two policies with the exact same matchers
have non-empty settings that are not the same (the one exception being
any_tag which we can merge because the logic for them is to OR them).
It was a bit complicated. It seems to work in numerous tests I've
conducted, but we'll see how it pans out in the release candidates.
If a site block has a key like "http://localhost:2016", then the log for
that site must be mapped to "localhost:2016" and not just "localhost"
because "localhost:2016" will be the value of the Host header of requests.
But a key like "localhost:80" does not include the port since the Host
header will not include ":80" because it is a standard port.
Fixes https://caddy.community/t/v2-common-log-format-not-working/7352?u=matt
See https://caddy.community/t/v2-match-any-path-but-files/7326/8?u=matt
If rewrites (or redirects, for that matter) match on file existence,
the file matcher would need to know the root of the site.
Making this change implies that root directives that depend on rewritten
URIs will not work as expected. However, I think this is very uncommon,
and am not sure I have ever seen that. Usually, dynamic roots are based
on host, not paths or query strings.
I suspect that rewrites based on file existence will be more common than
roots based on rewritten URIs, so I am moving root to be the first in
the list.
Users can always override this ordering with the 'order' global option.
