* Allow Response Headers in logs
* Remove log line
* remove unneeded log import
* Check if rr is nil. Added test to check
* merge if statements
* remove temp file
* Trim path prefix using EscapedPath()
* clarify comments
* Added Tests for trimPathPrefix
* Ensure path with trailing slash is properly trimmed
* Updated tests to match prepatch behaviour
* Updated tests to match prepatch behaviour
* call parse on url rather than instance
* add additional tests
* return unmodified url if error. Additional tests
Only strip the port from the Location URL value if the port is NOT the
HTTPSPort (before, we compared against DefaultHTTPSPort instead of
HTTPSPort). The HTTPSPort can be changed, but is done so for port
forwarding, since in reality you can't 'change' the standard HTTPS port,
you can only forward it.
See discussion on #2015; the initial change had removed this check, and
I can't remember why I removed it or if it was accidental. Anyway, it's
back now.
See discussion on #2015 for how this situation was discovered. For a
Caddyfile like this:
localhost {
...
}
:2015 {
...
}
Running Caddy like this:
caddy -host localhost
Produces two sites both defined as `localhost:2015` because the flag
changes the default host value to be `localhost`. This should be an
error since the sites are not distinct and it is confusing. It can also
cause issues with TLS handshakes loading the wrong cert, as the linked
discussion shows.
Also introduce caddy.OnProcessExit which is a list of functions that
run before exiting the process cleanly; these do not count as shutdown
callbacks, so they do not return errors and must execute quickly.
Fixes#1961
According to RFC 7231 and RFC 7230, there's
no reason a GET-Request can't have a body
(other than it possibly not being supported
by existing software). It's use is simply not
defined, and is left to the application.
- Expose the list of Caddy instances through caddy.Instances()
- Added arbitrary storage to caddy.Instance
- The cache of loaded certificates is no longer global; now scoped
per-instance, meaning upon reload (like SIGUSR1) the old cert cache
will be discarded entirely, whereas before, aggressively reloading
config that added and removed lots of sites would cause unnecessary
build-up in the cache over time.
- Key certificates in the cache by their SHA-256 hash instead of
by their names. This means certificates will not be duplicated in
memory (within each instance), making Caddy much more memory-efficient
for large-scale deployments with thousands of sites sharing certs.
- Perform name-to-certificate lookups scoped per caddytls.Config instead
of a single global lookup. This prevents certificates from stepping on
each other when they overlap in their names.
- Do not allow TLS configurations keyed by the same hostname to be
different; this now throws an error.
- Updated relevant tests, with a stark awareness that more tests are
needed.
- Change the NewContext function signature to include an *Instance.
- Strongly recommend (basically require) use of caddytls.NewConfig()
to create a new *caddytls.Config, to ensure pointers to the instance
certificate cache are initialized properly.
- Update the TLS-SNI challenge solver (even though TLS-SNI is disabled
currently on the CA side). Store temporary challenge cert in instance
cache, but do so directly by the ACME challenge name, not the hash.
Modified the getCertificate function to check the cache directly for
a name match if one isn't found otherwise. This will allow any
caddytls.Config to be able to help solve a TLS-SNI challenge, with one
extra side-effect that might actually be kind of interesting (and
useless): clients could send a certificate's hash as the SNI and
Caddy would be able to serve that certificate for the handshake.
- Do not attempt to match a "default" (random) certificate when SNI
is present but unrecognized; return no certificate so a TLS alert
happens instead.
- Store an Instance in the list of instances even while the instance
is still starting up (this allows access to the cert cache for
performing renewals at startup, etc). Will be removed from list again
if instance startup fails.
- Laid groundwork for ACMEv2 and Let's Encrypt wildcard support.
Server type plugins will need to be updated slightly to accommodate
minor adjustments to their API (like passing in an Instance). This
commit includes the changes for the HTTP server.
Certain Caddyfile configurations might error out with this change, if
they configured different TLS settings for the same hostname.
This change trades some complexity for other complexity, but ultimately
this new complexity is more correct and robust than earlier logic.
Fixes#1991Fixes#1994Fixes#1303
* shutdown: allow graceful shutdown for SIGTERM on posix
The signal is already trapped; make it do the same thing as SIGQUIT to
be more inline with Unix/Linux shutdown expectations.
Fixes#1993
* Implement comment feedback ideas
* caddymain: fix setCPU silently ignoring small percent values
the percent value is resolved in a GOMAXPROCS relative number by simple
division, thus rounding down the non-integer quotient. If zero, the call
to runtime.GOMAXPROCS is silently ignored.
We decide here to exceptionally round up the CPU cap in case of percent
values that are too small.
* caddymain: gofmt -s
* Update README.md
I believe the owner and group of the `chown` command here are mixed up. As it was caused a permissions issue, with the service being unable to read the directory.
* Update README.md
* Update README.md
Revert changes back to the original suggested changes
* First working mask
* IP Mask working with defaults and empty
* add tests for ipmask
* Store Mask as setup, some tidying, cleaner flow
* Prevent mask from running when directive not present
* use custom replacement to store masked ip
This adds the ask sub-directive to tls that defines the URL of a backend HTTP service to be queried during the TLS handshake to determine if an on-demand TLS certificate should be acquired for incoming hostnames. When the ask sub-directive is defined, Caddy will query the URL for permission to acquire a cert by making a HTTP GET request to the URL including the requested domain in the query string. If the backend service returns a 2xx response Caddy will acquire a cert. Any other response code (including 3xx redirects) are be considered a rejection and the certificate will not be acquired.
The rc.subr framework already takes care of substituting user. So, using
daemon's -u option is double user-substitution and fails if $caddy_user
is non-root.
caddy.go:569: could be simplified
sigtrap_posix.go:87: value of inst is never used
upgrade.go:151: should omit nil check; len() for nil slices is defined as zero
A default of true is risky when protecting assets by matching base path.
It's not obvious that protecting /foo/ will allow /Foo/ through, and if
accessing static files on a case-insensitive file system... that's no
good. So the default is now to be case-INsensitive when matching paths.
When two Caddyfiles with the same name, but different paths, are
imported, it can cause a weird bug because isNewLine() returned false
when it should return true, since the files are actually different,
but it couldn't know that because only the base name was stored,
not the whole path.
This change eliminates the `[ERROR] Could not write pidfile: open /var/run/caddy.pid: permission denied` from caddy.log.
The start-stop-daemon writes the file as root so the DAEMONUSER that caddy runs as cannot write to the .pid file.
* Proxy can now use QUIC for upstream connections
Add HandshakeTimeout, change h2quic syntax
* Add setup and upstream test
Test QUIC proxy with actual h2quic instance
Use different port fo QUIC test server
Add quic host to CI config
Added testdata to vendor
Revert "Added testdata to vendor"
This reverts commit 959512282deed8623168d090e5ca5e5a7933019c.
* Use local testdata
Renewed certificates would not be reloaded into the cache because their
names conflict with names of certificates already in the cache; this
was intentional when loading new certs to avoid confusion, but is
problematic when renewing, since the old certificate doesn't get
evicted from the cache. (Oops.)
Here, I remedy this situation by explicitly deleting the old cert from
the cache before adding the renewed one back in.
(See EULA.) Personally-licensed official Caddy builds cannot remove
this header by configuration. The commercially-licensed builds of Caddy
don't have this header.
* Allow pushing multiple resources via Link header
* Add nopush test case
* Extract Link header parsing to separate function
* Parser regexp-free
* Remove dead code, thx gometalinter
* Redundant condition - won't happen
* Reduce duplication
* browse: Attempt to fix tests on Windows
* browse: Make tests verbose for debugging
* Moar debugging
* Trying path.Join instead
* browse: Just skip the tests for now
* browse: Remove debug prints
build.go is (should be) cross-platform compatible.
Timestamps are now excluded from all builds on a clean commit,
in an effort to be byte-for-byte reproducible.
* templates: Execute template loaded by later middlewares
This is the beginning of an attempt to make the staticfiles file server
the only middleware that hits the disk and loads content. This may have
unknown implications. But the goal is to reduce duplication without
sacrificing performance. (We now call ServeContent here.)
This change loses about 15% of the req/sec of the old way of doing it,
but this way is arguably more correct since the file server is good at
serving static files; duplicating that logic in every middleware that
needs to hit the disk is not practical.
* httpserver: Introduce ResponseRecorder as per Tw's suggestions
It implements io.ReaderFrom and has some allocation-reducing
optimizations baked into it
* templates: Increase execution speed by ~10-15% after perf regression
By using httpserver.ResponseBuffer, we can reduce allocations and still
get what we want. It's a little tricky but it works so far.
The previous setting caused the service to hit a rate-limit when it was
restarted more than 5 times in 24h.
Editing the Caddyfile and restarting the service could also easily
trigger this rate limit.
One could argue that users could simply call `systemctl reset-failed
caddy` to reset the rate-limit counter, but this is counterintuitive
because most users won't know this command and are possibly unaware that
they had hit a rate-limit.
The service is now allowed to restart 10 times in 10 seconds before
hitting a rate limit.
This should be conservative enough to rate limit quickly failing
services and to allow users to edit and test their caddy configuration.
This closes#1718
Remove restart limit settings and use defaults
By default 5 restarts within 10 seconds are allowed without
encountering a restart limit hit, see `man systemd.unit` for details.
Set Restart to on-abnormal
The table in https://www.freedesktop.org/software/systemd/man/systemd.service.html#Restart=
shows the conditions for which on-abnormal would restart the service.
It will *not* restart the service in the following cases:
- a non-zero exit status, e.g. an invalid Caddyfile
- a zero exit code (or those specified in SuccessExitStatus=) and a clean signal
clean signals are SIGHUP, SIGINT, SIGTERM or SIGPIPE
https://github.com/systemd/systemd/blob/3536f49e8fa281539798a7bc5004d73302f39673/src/basic/exit-status.c#L205
The service *will be restarted* in the following cases:
- a unclean signal, e.g. SIGKILL
- on start and watchdog timeout (we don't use those systemd service
constructs explicitly)
* SIGUSR2 triggers graceful binary upgrades (spawns new process)
* Move some functions around, hopefully fixing Windows build
* Clean up a couple file closes and add links to useful debugging thread
* Use two underscores in upgrade env var
To help ensure uniqueness / avoid possible collisions
https://caddy.community/t/random-ocsp-response-errors-for-random-clients/2473?u=matt
Certificates are keyed by name in the cache, optimized for fast lookups
during TLS handshakes using SNI. A more "correct" way that is truly a
1:1 would be to cache certificates by a hash of the leaf's DER bytes,
but this involves an extra index to maintain. So instead of that, we
simply choose to prevent overlap when keying certificates by server
name. This avoids the ambiguity when updating OCSP staples, for instance.
Updated ifCondition test to deep test all fields.
Changed NewComplexRule to not return a pointer.
Corrected panic detection in formatting.
Fixed failing test cases.
Fixed review bug for test.
Fixes bug caused by Replacer running on the regular expressions in IfMatcher. We also now compile regular expressions up front to detect errors.
Fixes rewrite bugs that come from formatting a rule as a string and failing with nil dereference caused by embedding Regexp pointer in a Rule. Re: Issue #1794
0: normal or expected exit
1: error before server finished starting
2: double SIGINT (force quit)
3: error stopping with SIGQUIT
4: shutdown callback(s) returned error(s)
Use httpserver.IndexFile() to determine index files
Test if middleware pushes indexfile when requesting directory
Fix codereview issues
Serve original request first, push later
Revert "Serve original request first, push later"
This reverts commit 2c66f01115747e5665ba7f2d33e2fd551dc31877.
According to https://tools.ietf.org/html/rfc7232#section-2.1
> Likewise, a validator is weak if it is shared by two or more
representations of a given resource at the same time, unless those
representations have identical representation data. For example, if
the origin server sends the same validator for a representation with
a gzip content coding applied as it does for a representation with no
content coding, then that validator is weak.
Therefore, after gzip, we should change the original etag to weak etag.
* uses more of the builtin functionality for starting and stopping of the process by using command and command_args along with procname
* removed -f from daemon as this was hiding error message that were sent to stdout on startup, now writing stdout to the logfile directly
for example, this was being hidden:
“Activating privacy features.. [www.domain.com] failed to get certificate: Error presenting token: Could not find the start of authority”
it now shows up in the log
* aded “caddy_env” to allow the setting of environment variables that caddy might need, for example when setting creds for “DNS Challenge”
* added a check to ensure caddy_config_path file exists
go vet caused a build fail in https://travis-ci.org/mholt/caddy/jobs/248392875:
upstream_test.go:480::error: possible formatting directive in Error call (vet)
This patch changes the Error call added in commit 078c991574 to
an Errorf call to support the use of the %d token.
* vendor: update Lumberjack dep
* httpserver/roller: introduce rotate_compress directive
This directive will enable gzip compression provided by [Lumberjack](https://github.com/natefinch/lumberjack/pull/43).
The directive `rotate_compress` can be `true` or `false`, being `false` by default.
* httpserver/roller: remove need to set bool with rotate_compress option
See discussion on commit c9b022b5e0
If we overwrite the Server header, it becomes difficult/impossible to
know from the client whether the request was proxied through Caddy.
* introduced own ChallengeProvider type, based on acme.ChallengeProvider to avoid vendoring/version mismatches in Caddy plugins; see Caddy issue #1697
* fixed up comments for ChallengeProvider
* moved ChallengeProvider to caddytls/tls.go
* Browse: Show symbolic links and targets type properly
* gofmt
Signed-off-by: Jonas Östanbäck <jonas.ostanback@gmail.com>
* Move symbolic link check in to isSymlinkTargetDir
Signed-off-by: Jonas Östanbäck <jonas.ostanback@gmail.com>
* Revert template change and show sym link folders as normal folders
* browse: Updated icons including symlink indicators
The vendor/ folder was created with the help of @FiloSottile's gvt and
vendorcheck.
Any dependencies of Caddy plugins outside this repo are not vendored.
We do not remove any unused, vendored packages because vendorcheck -u
only checks using the current build configuration; i.e. packages that
may be imported by files toggled by build tags of other systems.
CI tests have been updated to ignore the vendor/ folder. When Go 1.9 is
released, a few of the go commands should be revised to again use ./...
as it will ignore the vendor folder by default.
* Add not_starts_with condition.
This adds the opposite of the starts_with condition, to check if a
given string does not start with another string.
* Correct white space problems
* Add uri policy test cases
* Add function definition
* Add uri hashing policy
* Refactor and extract hostByHashing and use in IP and URI policy
* Rename to URIHash
Signed-off-by: Jonas Östanbäck <jonas.ostanback@gmail.com>
* proxy: added 'health_check_port' to upstream
* proxy: `net.JoinHostPort` instead of `fmt.Printf` for upstream checks
* proxy: changing health_check_port type (int->string)
adding tests for invalid port config
Previously, the `Include` override used with the markdown plugin did not
provide the optional `args` parameter. This made it impossible to pass
arguments to a template used with that plugin.
* httpserver/all: Clean up and standardize request URL handling
The HTTP server now always creates a context value on the request which
is a copy of the request's URL struct. It should not be modified by
middlewares, but it is safe to get the value out of the request and make
changes to it locally-scoped. Thus, the value in the context always
stores the original request URL information as it was received. Any
rewrites that happen will be to the request's URL field directly.
The HTTP server no longer cleans /sanitizes the request URL. It made too
many strong assumptions and ended up making a lot of middleware more
complicated, including upstream proxying (and fastcgi). To alleviate
this complexity, we no longer change the request URL. Middlewares are
responsible to access the disk safely by using http.Dir or, if not
actually opening files, they can use httpserver.SafePath().
I'm hoping this will address issues with #1624, #1584, #1582, and others.
* staticfiles: Fix test on Windows
@abiosoft: I still can't figure out exactly what this is for. 😅
* Use (potentially) changed URL for browse redirects, as before
* Use filepath.ToSlash, clean up a couple proxy test cases
* Oops, fix variable name
* Raise syntax error if no '/' prefix to rewrite. Added Tests
* fix case where to keyword is used.
* Fixed spelling issue
* Changes to use Errf rather than new Err function
* Remove new RewritePathErr Function
* update to match same paths as systemd
* update to match new launchd plist
* generated from scratch with LaunchControl, flawless
Had some issues with the previous go and found LaunchControl which made it easy to generate a perfectly correct launchd conf
* Update README.md
* Disable warning for insecure CA if located on private network.
* Add IsPrivateNetwork function
* Add tests
Signed-off-by: Jonas Östanbäck <jonas.ostanback@gmail.com>
* Add more testcases
Signed-off-by: Jonas Östanbäck <jonas.ostanback@gmail.com>
* Rename IsPrivateNetwork -> IsInternal
Signed-off-by: Jonas Östanbäck <jonas.ostanback@gmail.com>
Original feature request in forum:
https://forum.caddyserver.com/t/caddy-with-specific-hosts-but-on-demand-tls/1704?u=matt
Before, Caddy obtained certificates for every name it could at startup.
And it would only obtain certificates during the handshake for sites
defined with a hostname that didn't qualify at startup (like
"*.example.com" or ":443"). This made sense for most situations, and
helped ensure that certificates were obtained as early and reliably as
possible.
With this change, Caddy will NOT obtain certificates for hostnames it
knows at startup (even if they qualify) if OnDemand is enabled.
But I think this change generalizes well, because a user who specifies
max_certs is deliberately turning on On-Demand TLS, fully aware of
the consequences. It seems dubious to ignore that config when the user
deliberately put it there. We'll see how this goes.
* Create list of index files based on extensions and check on a per config
basis
* remove log lines
* fixed tests
* made gofmt suggested change
* Changes made to simplify
* Respect the 'insecure_skip_verify' for the health check.
* WIP: Trying to add a test. Non functional.
* Fixing tests.
* Creating better error messages.
* Optimize two more error messages.
* Move the tests into an extra function.
* Add a shutdown function and context to staticUpstream so that running goroutines can be cancelled. Add a GetShutdownFunc to Upstream interface to expose the shutdown function to the caddy Controller for performing it on restarts.
* Make fakeUpstream implement new Upstream methods.
Implement new Upstream method for fakeWSUpstream as well.
* Rename GetShutdownFunc to Stop(). Add a waitgroup to the staticUpstream for controlling individual object's goroutines. Add the Stop function to OnRestart and OnShutdown. Add tests for checking to see if healthchecks continue hitting a backend server after stop has been called.
* Go back to using a stop channel since the context adds no additional benefit.
Only register stop function for onShutdown since it's called as part of restart.
* Remove assignment to atomic value
* Incrementing WaitGroup outside of goroutine to avoid race condition. Loading atomic values in test.
* Linting: change counter to just use the default zero value instead of setting it
* Clarify Stop method comments, add comments to stop channel and waitgroup and remove out of date comment about handling stopping the proxy. Stop the ticker when the stop signal is sent
Previously directories have been merely pulled to the front, and then
sorted arbitrarily. That is, their order among themselves depended on
the filesystem implementations. Something opaque to the visitor.
This fixes said inconsistency, and implements the by-size-then-by-name
order I initially intended for this.
* Use helper functions in staticfiles to redirect.
Previously the browse package invoked staticfiles.Redirect when
redirecting clients who requested a directory but with a Request-URI
that did not contain a trailing '/'. staticfiles.Redirect only used a
relative URI. This change defers the decision of how to format the
Location header value to the helper methods in the staticfiles package.
* Update const URLPathCtxKey in browse package.
* Add the first policy which sends the request to the first available host
* Make the error message clear. As we expect the second not first upstream
host.
* Fixed issue with {path} actually {uri}
* Test added for path rewrite
* add in uri_escaped
* added rewrite_uri and test
* fix broken test. Just checks for existance of rewrite header
* gitignore
* Use context to store uri value
* ignore .vscode
* tidy up, removal of comments and invalidated tests
* Remove commented out code.
* added comment as requested by lint
* fixed spelling mistake
* clarified code with variable name
* added context for uri and test
* added TODO comment to move consts
* Fixed#1484
Fixed a nil pointer runtime error in newConnHijackerTransport,
where the access to the TLSClientConfig did not check for nil values.
* Minor improvement to UseInsecureTransport
This prevents overwriting a possibly preexisting TLSClientConfig,
even though only a single field should be changed.
* add support for listener middleware
* add proxyprotocol directive
* make caddy.Listener interface required
* Remove tcpKeepAliveListener wrapper from Serve()
This is now done in the Listen() function, along with other potential middleware.
* Fix for missing content-length header when using QUIC
If request.ContentLength is set then it will be used instead of getting
it from request.Header map since quic-go(lucas-clemente/quic-go@bb24be8)
will not store (and pass) the Content-Length header using its header
map.
This fixes a potential issue where FastCGI POST requests body empty when
QUIC is enabled. (#1370)
* Change the data type for fastcgi contentLength to int64
quic-go uses int64 for contentLength
* Fix an error for undeclared variable
* Fix test for fcgiclient
the data type for contentLength
* Support realms with basic authentication
* Add test for default basicauth directive in which realm is not specified
* Correct typo: missing space
* Remove 'path' subdirective
This could have just as easily been a tls directive property in the
Caddyfile, but I figure if these challenges are being disabled, it's
because of port availability or process privileges, both of which would
affect all sites served by this process. The names of the flag are long
but descriptive.
I've never needed this but I hear of quite a few people who say they
need this ability, so here it is.
If use gzip and templates at the same time, the response body will
be gzipped data. And in this case, the Content-Type header won't be
set by Caddy code. Then Go http package will set "Content-Type" to
wrong value "application/x-gzip" which is determined by response body.
So the header Contenty-Type should be set in templates middleware.
This commit removes _almost_ all instances of hard-coded ports 80 and
443 strings, and now allows the user to define what the HTTP and HTTPS
ports are by the -http-port and -https-ports flags.
(One instance of "80" is still hard-coded in tls.go because it cannot
import httpserver to get access to the HTTP port variable. I don't
suspect this will be a problem in practice, but one workaround would be
to define an exported variable in the caddytls package and let the
httpserver package set it as well as its own HTTPPort variable.)
The port numbers required by the ACME challenges HTTP-01 and TLS-SNI-01
are hard-coded into the spec as ports 80 and 443 for good reasons,
but the big question is whether they necessarily need to be the HTTP
and HTTPS ports. Although the answer is probably no, they chose those
ports for convenience and widest compatibility/deployability. So this
commit also assumes that the "HTTP port" is necessarily the same port
on which to serve the HTTP-01 challenge, and the "HTTPS port" is
necessarily the same one on which to serve the TLS-SNI-01 challenge. In
other words, changing the HTTP and HTTPS ports also changes the ports
the challenges will be served on.
If you change the HTTP and HTTPS ports, you are responsible for
configuring your system to forward ports 80 and 443 properly.
Closes#918 and closes#1293. Also related: #468.
* Use RequestURI when redirecting to canonical path.
Caddy may trim a request's URL path when it starts with the path that's
associated with the virtual host. This change uses the path from the request's
RequestURI when performing a redirect.
Fix issue #1327.
* Rename redirurl to redirURL.
* Redirect to the full URL.
The scheme and host from the virtual host's site configuration is used
in order to redirect to the full URL.
* Add comment and remove redundant check.
* Store the original URL path in request context.
By storing the original URL path as a value in the request context,
middlewares can access both it and the sanitized path. The default
default FileServer handler will use the original URL on redirects.
* Replace contextKey type with CtxKey.
In addition to moving the CtxKey definition to the caddy package, this
change updates the CtxKey references in the httpserver, fastcgi, and
basicauth packages.
* httpserver: Fix reference to CtxKey
Timeouts are important for mitigating slowloris, yes. But after a number
of complaints and seeing that default timeouts are a sore point of
confusion, we're disabling them now. However, the code that sets
default timeouts remains intact; the defaults are just the zero value.
While Caddy aims to be secure by default, Caddy also aims to serve a
worldwide audience. Even my own internet here in Utah is poor at times,
with bad WiFi signal, causing some connections to take over 10s to
be established. Many use the Internet while commuting on slower
connection speeds. Latency across country borders is another concern.
As such, disabling default timeouts will serve a greater population of
users than enabling them, as slowloris is easy to mitigate and does
not seem to be reported often (I've only seen it once). It's also very
difficult sometimes to distinguish slowloris from genuine slow networks.
That decision is best left to the site owner for now.
* tls: Refactor TLS config innards with a few minor syntax changes
muststaple -> must_staple
"http2 off" -> "alpn" with list of ALPN values
* Fix typo
* Fix QUIC handler
* Inline struct field assignments
* Store name of authenticated user in basicauth for use by upstream middleware such as fastcgi and cgi.
* Use request context to transfer name of authorized user from basicauth to upstream middleware. Test retrieval of name from context.
* Remove development code that was inadvertently left in place
* Use keys of type httpserver.CtxKey to access Context values
* WIP: Implement HTTPS interception detection by Durumeric, et. al.
Special thanks to @FiloSottile for guidance with the custom listener.
* Add {{.IsMITM}} context action and {mitm} placeholder
* Improve MITM detection heuristics for Firefox and Edge
* Add tests for MITM detection heuristics
* Improve Safari heuristics for interception detection
* Read ClientHello during first Read() instead of during Accept()
As far as I can tell, reading the ClientHello during Accept() prevents
new connections from being accepted during the read. Since Read() should
be called in its own goroutine, this keeps Accept() non-blocking.
* Clean up MITM detection handler; make possible to close connection
* Use standard lib cipher suite values when possible
* Improve Edge heuristics and test cases
* Refactor MITM checking logic; add some debug statements for now
* Fix bug in MITM heuristic tests and actual heuristic code
* Fix gofmt
* Remove debug statements; preparing for merge
* fixing panic when root is symlink
checking root path is a symlink before os.Stat which panics
* fixing formatting
* adding test to verify symlink root path check
* fixing typo
* Add request placeholder support for querying request cookies.
This adds the ability to query the request cookies for placeholders
using the syntax "@cookiename".
For example, this would allow rewriting based on a cookie:
rewrite {
if @version is 'dev'
to /dev/index.html
}
* Switch cookie special char from @ to :
* Switch special char for cookies from : to ~
* Fix data race for max connection limiting in proxy directive.
The Conns and Unhealthy fields are updated concurrently across all active
requests. Because of this, they must use atomic operations for reads and
writes.
Prior to this change, Conns was incremented atomically, but read unsafely.
Unhealthly was updated & read unsafely. The new test
TestReverseProxyMaxConnLimit exposes this race when run with -race.
Switching to atomic operations makes the race detector happy.
* oops, remove leftover dead code.
* Use new subdirectives and flatten rolling config
* Set default rotate config
* Set default rolling config (hopefully) errwhere
* Make private
* Flatten errors directive and remove c.IncrNest()
* Don't skip first error log roller subdirective we see
* Remove hadBlock
* Try lumberjack import
* Unname import
The standard lib pprof library doesn't set its own Content-Type header
properly. If pprof is used with gzip, the index endpoint will be
interpreted as a .gz file; so we force its hand and set the header.
* proxy: use a new context for the outgoing request
fix issue #1345
Signed-off-by: Tw <tw19881113@gmail.com>
* proxy: add test for canceling the request
Signed-off-by: Tw <tw19881113@gmail.com>
* Generate meta elements from useful front matters.
Limited to the default template and specific elements.
* Rerun gofmt
* Add "keywords" and remove "language" to/from the list of meta tags.
* Add a simple positive list test for the meta tag generation.
* Move the meta tag list to a var at the begin of the file.
Seperate the Meta tags from the other front matters:
- Don't override user settings with name `meta`
- Cleaner Code.
* Remove the uneccessary `[:]` in the []Bytes to String casting.
@mholt was right ;)
* One minor refinement. Combining two statements.
The loop which performs renewals in the background obtains a read lock
on the certificate cache map, so that it can be safely iterated. Before
this fix, it would obtain the renewals in the read lock. This has been
fine, except that the TLS-SNI challenge, when invoked after Caddy has
already started, requires adding a certificate to the cache. Doing this
requires an exclusive write lock. But it cannot obtain a write lock
because a read lock is obtained higher in the stack, while the loop
iterates. In other words, it's a deadlock.
I was able to reproduce this issue consistently locally, after jumping
through many hoops to force a renewal in a short time that bypasses
Let's Encrypt's authz caching. I was also able to verify that by queuing
renewals (like we do deletions and OCSP updates), lock contention is
relieved and the deadlock is avoided.
This only affects background renewals where the TLS-SNI(-01) challenge
are used. Users report seeing strange errors in the logs after this
happens ("tls: client offered an unsupported, maximum protocol version
of 301"), but I was not able to reproduce these locally. I was also not
able to reproduce the leak of sockets which are left in CLOSE_WAIT.
I am not sure if those are symptoms of running in production on Linux
and are related to this bug, or not.
Either way, this is an important fix. I do not yet know the ripple
effects this will have on other symptoms we've been chasing. But it
definitely resolves a deadlock during renewals.
Because of this commit(6e36811c37399d60cbce587b7c48e611009c5aec) on go tip,
it will probe the request's body to determine whether to use chunked transfer
encoding which trailers depend on it.
So we just offer a non empty body to make trailers work.
fix issue #1359
Signed-off-by: Tw <tw19881113@gmail.com>
* Add {whenISO} to record timestamp in ISO 8601 format in UTC.
ISO 8601 is the standard time format and is easy to parse.
This change assumes users desiring ISO 8016 generally prefer UTC for simplicity.
This results in {whenISO} to be significantly shorter than {when}:
{when} = "02/Jan/2006:15:04:05 +0000"
{whenISO} = "2006-01-02T15:04:12Z"
Add unit test to verify both, as there was no unit test for {when}.
* Rename {whenISO} to {when_iso}
* Allow -validate flag to validate caddyfile and return
* Ensure logging without -log flag
* Changes to validate seperatly to Starup func
* Removed change to Start signature. Created function to ValidateCaddyfile
* comment and tidyup
* ValidateandExecuteDirectives with justValidate option
* remove debugging code
* Tidy up comments
* additional parameter added to calls to mustLogFataf
* ValidateAndExecuteDirectives needs to only return err
If only one upstream is defined we don't need to buffer the body.
Instead we directly stream the body to the upstream host,
which reduces memory usage as well as latency.
Furthermore this enables different kinds of HTTP streaming
applications like gRPC for instance.
If a site owner protects a path with basicauth, no need
to use the Authorization header elsewhere upstream, especially since it
contains credentials.
If this breaks anyone, it means they're double-dipping. It's usually
good practice to clear out credentials as soon as they're not needed
anymore. (Note that we only clear credentials after they're used,
they stay for any other reason.)
* Added path cleanup functions with masking to preserve certain patterns + unit tests, #1298
* Use custom PathClean function instead of path.Clean to apply masks to preserve protocol separator in the path
* Indentation corrected in the test data map to pass the lint
* Fixing ineffassign of a temporary string variable
* Improved variable naming and documentation
* Improved variable naming
* Added benchmarks and improved variable naming in tests
* Removed unnecessary value capture when iterating over a map for keys
* A typo correction
This issue was caused by connHijackerTransport trying to record HTTP
response headers by "hijacking" the Read() method of the plain net.Conn.
This does not simply work over TLS though since this will record the TLS
handshake and encrypted data instead of the actual content.
This commit fixes the problem by providing an alternative transport.DialTLS
which correctly hijacks the overlying tls.Conn instead.
* Fixed HTTP/2 support for the proxy middleware
http.Transport instances whose TLSClientConfig, Dial, or DialTLS field
is non-nil will be configured without HTTP/2 support by default.
This commit adds the proper calls to http2.ConfigureTransport()
everywhere a http.Transport is created and thus fixes HTTP/2 in the
proxy middleware whenever insecure_skip_verify or keepalive is provided.
* Added HTTP/2 support check to TestReverseProxyInsecureSkipVerify
* Feature #1282 - Support pre-gzipped files
* Fix broken test cases
* Support brotli encoding as well
* Fix for #1276 - support integers and floats as metadata in markdown (#1278)
* Fix for #1276
* Use strconv.Format
* Use map[string]interface{} as variables
* One more file
* Always run all tests before commit
* Get rid of DocFlags
* Fix syntax in caddy.conf
* Update to Go 1.7.4
* Add send_timeout property to fastcgi directive.
* Convert rwc field on FCGIClient from type io.ReadWriteCloser to net.Conn.
* Return HTTP 504 to the client when a timeout occurs.
* In Handler.ServeHTTP(), close the connection before returning an HTTP
502/504.
* Refactor tests and add coverage.
* Return HTTP 504 when FastCGI connect times out.
* test: add unit test for #1283 (#1288)
* After review fixes
* Limit the number of restarts with systemd
* Prevent fd leak
* Prevent fd leak
* Refactor loops
* gofmt
* Convert rwc field on FCGIClient from type io.ReadWriteCloser to net.Conn.
* Return HTTP 504 to the client when a timeout occurs.
* In Handler.ServeHTTP(), close the connection before returning an HTTP
502/504.
* Refactor tests and add coverage.
* Fix for #1276
* Use strconv.Format
* Use map[string]interface{} as variables
* One more file
* Always run all tests before commit
* Get rid of DocFlags
By setting the read deadline in streamReader.Read(), the deadline was
extended by the read timeout on each subsequent call. To avoid this, the
deadline is set in FCGIClient.Request(), before the first read occurs.
See #1094.
* INIT-systemd use CADDYPATH instatt of HOME
* INIT-upstart use CADDYPATH instatt of HOME
* INIT-upstart use CADDYPATH instatt of HOME
* INIT-upstart use CADDYPATH instatt of HOME
* Filter empty headers
Some web servers (e.g. Jetty 9.3) don’t like HTTP headers with empty values. This commit filters header replacements with zero length.
* Extend tests to verify removal of empty headers
* Handle add-header case
* Change - Use short variable assignment
* Make fastcgi load balanceable too
* Address one more corner case - invalid configuration fastcgi /
* After review fixes
* Simplify conditions
* Error message
* New fastcgi syntax
* golint will be happy
* Change syntax
* Add Files action to template context. (#1198)
* Fixes to testFiles().
- Set os.ModePerm on directories created during test.
- Use filepath.Join() to create directory path.
- Use Fatalf, not Fatal.
* Make additional fixes to test cases.
* Fix test cases to use correct path format.
Dir.Open() in net/http requires '/'-separated paths while
filepath.Join() may produce paths with different separator.
* Remove directory created by test at end of loop.
* Close the FileSystem before returning.
* Initialize names slice to the number of entries.
Also, do not call os.RemoveAll() unless the path to the directory
is a valid one.
* Very simple fix for #1153
* Prevent Caddy-Rewrite-Original-URI being added as an HTTP ENV variable passed to FastCGI
part of fix for #1153
* Changes to Markdown to fix travis CI build.
#1955.2
* Revert "Changes to Markdown to fix travis CI build."
This reverts commit 4a01888839.
* fail fast and fmt changes
* Create test for existance of Caddy-Rewrite-Original-URI header value #1153
* updated test comment
* const moved outside function so available to tests
By calling SetTLSAddress, the acme package reset the challenge provider
to the default one instead of keeping the custom one we specified before
with SetChallengeProvider. Yikes. This means that Caddy would try to
open a listener on port 443 even though we should have been handling it
with our provider, causing the challenge to fail, since usually port 443
is in use.
So this change just reorders the calls so that our provider takes
precedence.
cf. https://github.com/xenolf/lego/pull/292
* Remove the eager check in the browse middleware, whether the root directory exists.
Caddy will start and throw a 404-error until the directory will be created.
* Add the complimentary test.
- Tests the startup of the browse middleware if the site root is inexistent and browse is pointing to the site root.
* Some minor stylistic tweaks.
* keep fastcgi connection open
* poor mans serialisation to make up for the lack of demuxing
* pointing includes to echse's repo
* Revert "pointing includes to echse's repo"
This reverts commit 281daad8d4.
* switch for persistent fcgi connections on/off added
* fixing ineffectual assignments
* camel case instead of _
* only activate persistent sockets on windows (and some naming conventions/cleanup)
* gitfm import sorting
* Revert "fixing ineffectual assignments"
This reverts commit 79760344e7.
# Conflicts:
# caddyhttp/staticfiles/fileserver.go
* added another mutex and deleting map entries. thx to mholts QA comments!
* thinking about it, this RW lock was not a good idea here
* thread safety
* I keep learning about mutexs in go
* some cosmetics
* adding persistant fastcgi connections switch to directive
* Support for configurable connection pool.
* ensure positive integer pool size config
* abisofts pool fix + nicer logging for the fastcgi_test
* abisoft wants to have dialer comparison in _test instead of next to struct
* Do not put dead connections back into pool
* Fix fastcgi header error
* Do not put dead connections back into pool
* some code style improvements from the discussion in https://github.com/mholt/caddy/pull/1134
* abisofts naming convention
* Remove unnecessary config options from systemd service so it will work with earlier versions of systemd. Simplify the systemd service instructions and make them more complete.
* Minor systemd README improvements.
* Add back some of the optional systemd 229 stuff but commented out for compat.
* A bunch of updates to the README for linux systemd.
* keep fastcgi connection open
* poor mans serialisation to make up for the lack of demuxing
* pointing includes to echse's repo
* Revert "pointing includes to echse's repo"
This reverts commit 281daad8d4.
* switch for persistent fcgi connections on/off added
* fixing ineffectual assignments
* camel case instead of _
* only activate persistent sockets on windows (and some naming conventions/cleanup)
* gitfm import sorting
* Revert "fixing ineffectual assignments"
This reverts commit 79760344e7.
# Conflicts:
# caddyhttp/staticfiles/fileserver.go
* added another mutex and deleting map entries. thx to mholts QA comments!
* thinking about it, this RW lock was not a good idea here
* thread safety
* I keep learning about mutexs in go
* some cosmetics
* Updated FreeBSD init script to allow the server to stop properly
* Fixed FreeBSD init script permissions
* Updated FreeBSD init script to allow the server to stop properly
We renamed caddytls.ErrStorageNotFound to caddytls.ErrNotExist to more
closely mirror the os package. We changed it to an interface wrapper
so that the custom error message can be preserved. Returning only "data
not found" was useless in debugging because we couldn't know the
concrete value of the error (like what it was trying to load).
Users can do a type assertion to determine if the error value is a "not
found" error instead of doing an equality check.
A Caddyfile using *.example.com as its site address would be subject to
this bug at renewal time, as it would use the literal "*.example.com"
value instead of the name being passed in to obtain a certificate.
This change fixes the LoadSite call so that it looks in the proper
directory for the certificate resources.
It was set by default on the caddy-internal config object, and even
checked for conflicts, but it was never actually reflected on the
tls.Config.
This will have user-visible changes: a client that prefers, say, AES-CBC
but also supports AES-GCM would have used AES-CBC befor this, and will
use AES-GCM after.
This is desirable and important behavior, because if for example the
server wanted to support 3DES, but *only if it was strictly necessary*,
it would have had no way of doing so with PreferServerCipherSuites
false, as the client preference would have won.
This function should not be used outside of development. It destroys the
absolute ordering and guarantees of correctness. Multiple uses of it
may work fine, but maybe not if they overlap, causing non-deterministic
builds which is bad. However, this can be convenient when developing
a plugin by calling it from an init() function, since you don't have
to modify the Caddy source code just to try your plugin.
Removing quic protocol headers from being persisted during proxy requests.
Not removing them could lead to the client attempting to connect to the wrong port.
This makes the quic headers consistent with other protocol headers.
Make ServerListeners public and add two helper methods to get access
to the address they listen on. This is useful for tests (among other
things)
Also make DefaultConfigFile a var so it can be overridden by server
types.
* * Added support for environment variables to 'templates' module.
* Fixed flaw in test caused by environment variable ordering during testing on CI.
* Updated some local variables to camel-case.
* Reverted changes to replacer as environment variables are processed elsewhere.
* Removed PrintEnv functionality in favour of documenting using template range.
If another ACME client is trying to solve a challenge for a name not
being served by Caddy on the same machine where Caddy is running, the
HTTP challenge will be consumed by Caddy rather than allowing the owner
to use the Caddyfile to proxy the challenge.
With this change, we only consume requests for HTTP challenges for
hostnames that we recognize. Before doing the challenge, we add the
name to a set, and when seeing if we should proxy the challenge, we
first check the path of course to see if it is an HTTP challenge;
if it is, we then check that set to see if the hostname is in the
set. Only if it is, do we consume it.
Otherwise, the request is treated like any other, allowing the owner
to configure a proxy for such requests to another ACME client.
* Fix for stripping of 'Content-Disposition' and other headers from 'X-Accel-Redirect' redirect scripts.
* Added test case for header manipulation of redirect response.
`$(which setcap)` might evaluate to nothing,
and this way the error thrown will be more clear.
If setcap is not available on Debian/Ubuntu,
you can install the package `libcap2-bin`
* dist/init/linux-sysvinit: pass --oknodo for --start as well
* dist/init/linux-sysvinit: manually rm PIDFILE
Since start-stop-daemon --remove-pidfile is new and not present
everywhere.
First, great job on the 0.9 release! It seems caddy's path lead into a bright future. Thanks also for including the locale plugin.
Trying it, I've figured out, that there might be a problem with the order of the directives. In the typical use case, the result of the locale detection might be used in the `rewrite` and `log` plugin. If I'm not mistaken, it makes sense to put the `locale` directive before those.
* Allow for UDP servers
Extend the Server interface with ServePacket and ListenPacket - this is
in the same vein as the net package.
Plumb the packetconn through the start and restart phases.
Rename RestartPair to RestartTriple as it now also contains a Packet.
Not that these can now be nil, so we need to check for that when
restarting.
* Update the documentation
* import should get absolute path before glob
* fix test: import should get absolute path before glob
* try to fix test on windows
* use complete path as the dispenser filename
* fix caddyfile test
* Initial concept for pluggable storage (sans tests and docs)
* Add TLS storage docs, test harness, and minor clean up from code review
* Fix issue with caddymain's temporary moveStorage
* Formatting improvement on struct array literal by removing struct name
* Pluggable storage changes:
* Change storage interface to persist all site or user data in one call
* Add lock/unlock calls for renewal and cert obtaining
* Key fields on composite literals
This is inconsistent with the other directives, but import is a special
case and frankly the behavior of import shouldn't change depending
on the directory from which you run caddy. Breaking change but I think
it's for the better, and best to do it now before 1.0.
If we listen on 127.0.0.1:80 for `localhost` but :80 for everything else,
then a hostname in the hosts file that resolves to 127.0.0.1 will be
served on :80 (unless the bind directive is used) but the OS will use
the socket listening at 127.0.0.1:80, thus giving a "No such site" error
even though the site is there, but it's on the other listener at :80.
Two ways to fix this: 1) Leave as-is and require the user to set "bind
127.0.0.1" in their Caddyfile for all sites that are resolved in the
hosts file, or 2) Take out this special case and let localhost sites
listen on :80 (unless the user changes that with the bind directive, of
course). Having localhost bind to any interface is a little annoying
(unsettling?) but probably best in the long run.
https://forum.caddyserver.com/t/wildcard-virtual-domains-with-wildcard-roots/221/9?u=matt
OnStartup and OnShutdown callbacks now run as part of restarts, too.
The startup and shutdown directives only run their commands NOT as part
of restarts, as before. Some middleware that use OnStartup may need to
switch to OnFirstStartup and implement OnFinalShutdown to do any cleanup
as needed.
* checkpoint
* Added RequestMatcher interface. Extract 'if' condition into a RequestMatcher.
* Added tests for IfMatcher
* Minor refactors
* Refactors
* Use if_op
* conform with new 0.9 beta function changes.
- Server types no longer need to store their own contexts; they are
stored on the caddy.Instance, which means each context will be
properly GC'ed when the instance is stopped. Server types should use
type assertions to convert from caddy.Context to their concrete
context type when they need to use it.
- Pass the entire context into httpserver.GetConfig instead of only the
Key field.
- caddy.NewTestController now requires a server type string so it can
create a controller with the proper concrete context associated with
that server type.
Tests still need more attention so that we can test the proper creation
of startup functions, etc.
* Add timeout to http get on health_check
* Add new test and up the timeout
* Tests for change to default timeout
* Only call http client once and make options more inline with current caddy directives
This commit shouldn't change any behavior. It is simply a cleanup of
the different proxy policies. It also adds some comments explaining the
sampling method used, since on first inspection it might not appear to
be a uniformly random selection.
* Balance round robin evenly when some hosts are down
Before, when load balancing across multiple hosts, if a host went down
then the next host in line would be sent a double share of requests.
This is because the round robin counter was only incremented once per
request, regardless of the health of the selection. If current
selection was unhealthy then the policy would advance to the next host,
but this would not be reflected in the policy counter. To fix this, the
counter is now incremented for every attempted host.
This commit adds a test case that identifies the issue, and a fix.
* Make robin counter private
* Use a mutex to sync round robin selection
Also we change the scheme of the site's address if TLS is enabled and
no other scheme is explicitly set; this makes it appear as "https" when
we print it; otherwise it would show "http" when TLS is turned on
implicitly, and that is confusing/incorrect.
These changes span work from the last ~4 months in an effort to make
Caddy more extensible, reduce the coupling between its components, and
lay a more robust foundation of code going forward into 1.0. A bunch of
new features have been added, too, with even higher future potential.
The most significant design change is an overall inversion of
dependencies. Instead of the caddy package knowing about the server
and the notion of middleware and config, the caddy package exposes an
interface that other components plug into. This does introduce more
indirection when reading the code, but every piece is very modular and
pluggable. Even the HTTP server is pluggable.
The caddy package has been moved to the top level, and main has been
pushed into a subfolder called caddy. The actual logic of the main
file has been pushed even further into caddy/caddymain/run.go so that
custom builds of Caddy can be 'go get'able.
The HTTPS logic was surgically separated into two parts to divide the
TLS-specific code and the HTTPS-specific code. The caddytls package can
now be used by any type of server that needs TLS, not just HTTP. I also
added the ability to customize nearly every aspect of TLS at the site
level rather than all sites sharing the same TLS configuration. Not all
of this flexibility is exposed in the Caddyfile yet, but it may be in
the future. Caddy can also generate self-signed certificates in memory
for the convenience of a developer working on localhost who wants HTTPS.
And Caddy now supports the DNS challenge, assuming at least one DNS
provider is plugged in.
Dozens, if not hundreds, of other minor changes swept through the code
base as I literally started from an empty main function, copying over
functions or files as needed, then adjusting them to fit in the new
design. Most tests have been restored and adapted to the new API,
but more work is needed there.
A lot of what was "impossible" before is now possible, or can be made
possible with minimal disruption of the code. For example, it's fairly
easy to make plugins hook into another part of the code via callbacks.
Plugins can do more than just be directives; we now have plugins that
customize how the Caddyfile is loaded (useful when you need to get your
configuration from a remote store).
Site addresses no longer need be just a host and port. They can have a
path, allowing you to scope a configuration to a specific path. There is
no inheretance, however; each site configuration is distinct.
Thanks to amazing work by Lucas Clemente, this commit adds experimental
QUIC support. Turn it on using the -quic flag; your browser may have
to be configured to enable it.
Almost everything is here, but you will notice that most of the middle-
ware are missing. After those are transferred over, we'll be ready for
beta tests.
I'm very excited to get this out. Thanks for everyone's help and
patience these last few months. I hope you like it!!
Provides some more guidelines to operators on how to avoid running Caddy as root.
Introduces an user www-data, which really is a placeholder. Such an user with the same UID/GID combination is created on the most popular Linux distribution. I trust any operator can spot the difference to his/her distro and adjust the unit file.
User nobody is not used here to avoid two easy pitfalls: Such an user should not be able to access private keys (for TLS), and should not write private keys (we would do that with Letsencrypt).
The exemplary unit file for systemd is intentionally redundant at times, for
example dropping privileges which an unprivileged user "www-data" did not have
in the first place: To aid as fallback in case the file gets copied and an
operator setting UID to 0 (which reportedly happened in the past).
* Overwrite proxy headers based on directive
Headers of the request sent by the proxy upstream can now be modified in
the following way:
Prefix header with `+`: Header will be added if it doesn't exist
otherwise, the values will be merge
Prefix header with `-': Header will be removed
No prefix: Header will be replaced with given value
* Add missing formating directive reported by go vet
* Overwrite up/down stream proxy headers
Add Up/DownStreamHeaders to UpstreamHost
Split `proxy_header` option in `proxy` directive into `header_upstream`
and `header_downstream`. By splitting into two, it makes it clear in
what direction the given headers must be applied.
`proxy_header` can still be used (to maintain backward compatability)
but its assumed to be `header_upstream`
Response headers received by the reverse proxy from the upstream host
are updated according the `header_downstream` rules.
The update occurs through a func given to the reverse proxy, which is
applied once a response is received.
Headers (for upstream and downstream) can now be modified in
the following way:
Prefix header with `+`: Header will be added if it doesn't exist
otherwise, the values will be merge
Prefix header with `-': Header will be removed
No prefix: Header will be replaced with given value
Updated branch with changes from master
* minor refactor to make intent clearer
* Make Up/Down stream headers naming consistent
* Fix error descriptions to be more clear
* Fix lint issue
* Move handling of headers around to prevent memory use spikes
While debugging #782, I noticed that using http2 and max_fails=0,
X-Forwarded-For grew infinitely when an upstream request failed after
refreshing the test page. This change ensures that headers are only
set once per request rather than appending in a time-terminated loop.
* Refactor some code into its own function
Those settings enforce convergence on common coding style with respect to whitespace.
Do not use tabs to indent with shell scripts because those tabs most often
serve the function of triggering command completion. Which could end a
command before it is pasted completely.
Traditionally indentation is two spaces here, not four.
Other rules will catch stray whitespace at the end of lines or files, which,
once committed, would annoy the next developer because his editor would strip
them from lines he did not intended to modify in the first place.
Fixes a surplus — next to "go up".
Identifies the preamble as the table's summary.
Emits filesizes in bytes, which can be consumed by any browser-side scripts
or utilized in sorting when the table is copy-and-pasted into a spreadsheet
software.
Uses <time> along with proper datetime representation, which a browser could
utilize to display the datetime rendered according to the requestor's locale.
Assigns negative sizes to directories in order to have them listed reliably
before any zero-sized files. That order is what most users expect when
sorting by size.
As side effect directories will appear before files on all filesystem
implementations. To give an example: before this change directories had a size
of 4 KiB when using Linux with ext4 or tmpfs, and with ZFS a size resembling
an estimation of the number of leaves within said directory.
* browse: Catch the case of a directory disappearing before having been read
* browse: Revert to old pass-through behaviour
PROPFIND is a request for an alternate view on a directory's contents, which
response is indeed not implemented but ideally allowed to ask for.
OPTIONS would ideally return (at least) what methods the requestor could use,
which is an allowed request method, too.
This addresses #767.
On matched header rules, replacer is used to replace any placeholders
defined in header rules iex. X-Backend {hostname} where {hostname} will
be replaced by the hostname key present in the replacer
hostname key added to replacer. The value is determined by the output of
`os.Hostname()`
Caddyfile parameter "clients" of "tls" henceforth accepts a special
first modifier. It is one of, and effects:
* request = tls.RequestClientCert
* require = tls.RequireAnyClientCert
* verify_if_given = tls.VerifyClientCertIfGiven
* (none) = tls.RequireAndVerifyClientCert
The use-case for this is as follows: A middleware would serve items to the
public, but if a certificate were given the middleware would permit file
manipulation.
And, in a different plugin such as a forum or blog, not verifying a client
cert would be nice for registration: said blog would subsequently only
compare the SPKI of a client certificate.
As discussed with @mholt I have dropped the old LinkedPath function and
replaced it within the browse template with the new BreadcrumbMap
function. Visually it looks exactly the same as before, now the template
functionality is just more powerful.
Signed-off-by: Thomas Boerger <tboerger@suse.de>
In order to being able to really build a custom template for the browse
directive I have added another function to build even custom breadcrumb
paths. The other function `LinkedPath` is not that easy styleable as
this map function. That way we are able to build the breadcrumb path
matching different CSS frameworks like Bootstrap.
Signed-off-by: Thomas Boerger <thomas@webhippie.de>
In order to have directly a link within the browse listing I have added
a link to the top of the table to get one level up in the tree. Added
that after a chat with @mholt.
Signed-off-by: Thomas Boerger <thomas@webhippie.de>
Nuke pre-generation. This may come back in the form of a more general
caching layer at some later stage.
Nuke index generation. This should likely be rethought and re-implemented.
Easier parallelism and more control over platforms we build for, but
more importantly, we can do parallel builds using the build script which
properly embeds version information into the binaries. We also produce
the archive files ourselves and in parallel rather than using external
tar and zip commands.
Caddy expects websocket to be completely lowercase.
Some applications send websocket upgrade headers like the following:
`Upgrade: WebSocket`
This change allows all variations of websocket.
Right now it has a very simple configuration:
expvar /debug/vars
It will return a JSON object with memory statistics and the command line
used to start caddy, which are the two expvars that expvar registers by
default.
When thy variables henceforth accept blessed white-space,
guided will thy scripture be along righteous path(s).
-- 4 BASH 3:42
Caddy's dist files sometimes ended up being owned by matt:staff or other
quite arcane and/or frightening names. If someone extracting didn't pay
attention a regular user who happened to have same uid by accident could
later tamper with the files' contents. It's 0:0 from now on.
Use all available threads when packaging distributables
Caddy binaries will be added to their archives in-place: This change
eliminates them being renamed within dist/builds one after another.
As does 'gox', dist/automate.sh will spare one available thread if possible.
Format of main.buildDate has been locale-dependent,
and is now ISO-8601 compliant.
Caddy displayed with ```-version``` something like (mind the datetime format):
Caddy 0.8.2 (+591b209 Fri Mar 18 21:22:55 UTC 2016)
2 files changed, 9 insertions(+), 4 deletions(-)
build.bash
main.go
which is now:
Caddy 0.8.2 (+591b209 2016-03-18 21:22:55Z)
2 files changed, 9 insertions(+), 4 deletions(-)
build.bash,main.go
See also:
* http://wiki.bash-hackers.org/scripting/obsolete
* https://google.github.io/styleguide/shell.xml
* https://xkcd.com/1179/
Unlike network.target the network-online.target guarantees that the network
devices are online.
If you bind to 0.0.0.0, [::], [::1], and/or 127.0.0.1 only that is enough to
proceed. But in case a particular IP is needed, like ${COREOS_PUBLIC_IPV4},
we require any IP assignments to have completed before Caddy's start. That
is achieved by depending on systemd-networkd-wait-online.service (which is
scheduled before network-online.target, then, automatically).
Add systemd service file for caddy
Add some README with basic setup instructions
Explain how to view the service configuration
Add a note about permissions
Add a comment about run user and group
service->service unit
A systemd service can consist of different units. A unit configuration
file has the `.service` file ending which is a bit confusing, so please
be considerate if I'm confusing `service` and `unit` in the README
Fix typos/reword
Add contact information
- The mime middleware used filepath where it should arguably use path.
- Changed the configuration to use a map instead of scanning an array
during every request. The map is static (after configuration), so
should be fine for concurrent access.
- Catch duplicate extensions within a configuration and error out.
- Add tests for new error case.
Minor change to server/server.go such that /.well-known/acme-challenge
can be passed through when TLS.Manual is true on the vhost the request
came in through.
fastcgi's ServeHTTP method originally returned the correct value (0) in
b51e8bc191. Later, I mistakenly suggested
we change that to return the status code because I forgot that status
codes aren't logged by the return value. So fastcgi broke due in
3966936bd6 due to my error.
We later had to try to make up for this with ugly Content-Length checks
like in c37ad7f677. Turns out that all we
had to do was fix the returned status here back to 0. The proxy
middleware behaves the same way, and returning 0 is correct. We should
only return a status code if the response has not been written, but with
upstream servers, we do write a response; they do not know about our
error handler.
Also clarifed this in the middleware.Handler documentation.
Without -ldflags, the verison information needs to be updated manually,
which is never done between releases, so development builds appear
indiscernable from stable builds using `caddy -version`.
This is part of a set of changes intended to relieve the burden of
always updating version information manually and distributing binaries
that look stable but actually may not be.
A stable build is defined as one which is produced at a git tag with
a clean working directory (no uncommitted changes). A dev build is
anything else. With this build script, `caddy -version` will now reveal
whether it is a development build and, if so, the base version, the
latest commit, the date and time of build, and the names of files with
changes as well as how many changes were made.
The output of `caddy -version` for stable builds remains the same.
Now attempt to staple OCSP even for certs that don't have an existing staple (issue #605). "tls off" short-circuits tls setup function. Now we call getEmail() when setting up an acme.Client that does renewals, rather than making a new account with empty email address. Check certificate expiry every 12 hours, and OCSP every hour.
This fixes a regression introduced in recent commits that enabled TLS on the default ":2015" config. This fix is possible because On-Demand TLS is no longer implicit; it must be explicitly enabled by the user by setting a maximum number of certificates to issue.
If Caddy is running but not listening on port 80, reloading Caddy with a new Caddyfile that needs to obtain a TLS cert from the CA would fail, because it was just assumed that, if reloading, port 80 as already in use. That is not always the case, so we scan the servers to see if one of them is listening on port 80, and we configure the ACME client accordingly. Kind of a hack... but it works.
Biggest change is no longer using standard library's tls.Config.getCertificate function to get a certificate during TLS handshake. Implemented our own cache which can be changed dynamically at runtime, even during TLS handshakes. As such, restarts are no longer required after certificate renewals or OCSP updates.
We also allow loading multiple certificates and keys per host, even by specifying a directory (tls got a new 'load' command for that).
Renamed the letsencrypt package to https in a gradual effort to become more generic; and https is more fitting for what the package does now.
There are still some known bugs, e.g. reloading where a new certificate is required but port 80 isn't currently listening, will cause the challenge to fail. There's still plenty of cleanup to do and tests to write. It is especially confusing right now how we enable "on-demand" TLS during setup and keep track of that. But this change should basically work so far.
This allows any template to use:
{{.Markdown "filename"}} which will convert the markdown contents
of filename to HTML and then include the HTML in the template.
Implements "on-demand TLS" as I call it, which means obtaining TLS certificates on-the-fly during TLS handshakes if a certificate for the requested hostname is not already available. Only the first request for a new hostname will experience higher latency; subsequent requests will get the new certificates right out of memory.
Code still needs lots of cleanup but the feature is basically working.
I've built this on Go 1.6 beta 1 and made some changes to be more compatible. Namely, I removed the use of the /x/net/http2 package and let net/http enable h2 by default; updated the way h2 is disabled (if the user requires it); moved TLS_FALLBACK_SCSV to the front of the cipher suites list (all values not accepted by http2 must go after those allowed by it); removed the NextProto default of http/1.1; set the http.Server.TLSConfig value to the TLS config used by the listener (we left it nil before, but this prevents automatic enabling of h2).
It is very likely there is more to do, but at least already Caddy uses HTTP/2 when built with Go 1.6.
This change fixes the scenario where you reload the config and it tries to obtain a cert from the ACME server, but no email address is found or terms have not been agreed to in-process. This is unfortunate but it should not stop the server from reloading, so we assume empty email address in this case.
It is unexpected to serve localhost on port 443 or any server on 443 if TLS is disabled, even if the port is blank. Also don't warn about how to force TLS on the HTTP port.
The docs link to this structure and all its methods related to the browse template; keeping them together makes it possible to link to the whole block of code that is relevant.
Before, Caddy couldn't support graceful (zero-downtime) restarts when the reloaded Caddyfile had a host in it that was elligible for a LE certificate because the port was already in use. This commit makes it possible to do zero-downtime reloads and issue certificates for new hosts that need it. Supports only http-01 challenge at this time.
OCSP stapling is improved in that it updates before the expiration time when the validity window has shifted forward. See 30c949085c. Before it only used to update when the status changed.
This commit also sets the user agent for Let's Encrypt requests with a string containing "Caddy".
By separating scheme and port at the parser, we are able to set the port appropriately and also keep the semantics of the scheme being specified by the user later on. The parser also stores an address' original input. Also, the config refactor makes it possible to partially load a config - valuable for determining which ones will need Let's Encrypt integration turned on during a restart.
We can't use json meta parser's remaining buffered data as the markdown body
because it may not contain the entire original content.
Now we adopt the way like toml and yaml parser's way to extract the meta content
at first.
Also when spilting the meta data and content body, additional io.Copy is
unnecessary.
Fix issue #355
Signed-off-by: Tw <tw19881113@gmail.com>
Made a faulty assumption that virualhosts could share acme proxy handlers; turns out they can't without fumbling up the middleware configuration (middleware chains overlap and cross over into other virtualhosts)!
Hosts which are eligible for automatic HTTPS have default port "https" but other hosts (wildcards, loopback, etc.) have the default port 2015. The default host of empty string should be more IPv6-compatible.
Instead of accessing the google website, we setup a local server
for test, then tests will work fine even we are offline.
Fix issue #346
Signed-off-by: Tw <tw19881113@gmail.com>
It no longer uses regular expressions.
It supports both the Unix `{$ENV_VAR}` _and_ the Windows `{%ENV_VAR%}`
syntax.
Added test for both Unix and Windows env. syntax.
Added a -grace flag to customize graceful shutdown period, fixed bugs related to closing file descriptors (and dup'ed fds), improved healthcheck signaling to parent, fixed a race condition with the graceful listener, etc. These improvements mainly provide better support for frequent reloading or unusual use cases of Start and Stop after a Restart (POSIX systems). This forum thread was valuable help in debugging: https://forum.golangbridge.org/t/bind-address-already-in-use-even-after-listener-closed/1510?u=matt
Fixed pidfile writing problem where a pidfile would be written even if child failed, also cleaned up restarts a bit and fixed a few bugs, it's more robust now in case of failures and with logging.
Whether the original parent process or a child process as part of a restart, the pidfile will not be written/changed until that process has started successfully. It is written every time caddy.Start() succeeds (may be reundant, but that's probably okay).
Actually, restart on posix systems failed entirely if caddy was executed without the path included; also fixed a related bug where a variable was declared but never assigned.
We had to hack some special support into the server and caddy packages for this. There are some middlewares which should only execute commands when the original parent process first starts up. For example, someone using the startup directive to start a backend service would not expect the command to be executed every time the config was reloaded or changed - only once when they first started the original caddy process.
This commit adds FirstStartup to the virtualhost config
Some programs (Node.js, supervisor, etc.) open a stdin pipe by default and don't use it, causing Caddy to block. It is their error, but we have to try to accommodate unfortunately. To fix this more universally, parent must explicitly set -conf to "stdin" to read from pipe.
The error channel used when starting all the servers must be buffered so that, even if there are no errors at startup, the returns that insert into the error channel will not be blocked, since after startup, nobody is reading that channel anymore.
The base path being optional in the Caddyfile is convenient when you just want the whole site to be markdown-enabled. The other change is to always generate links... this is because an index page for markdown files may not be statically generated, but it should still show links. Commit 09341fc was a regression, and this fixes it.
Previously, if a listener fails to bind (for example), there was a race in caddy.go between unblocking the startup waitgroup and returning the error and putting it into errChan. Now, an error is returned directly into errChan and the closing of the startup waitgroup is defered until after that return takes place.
Log file can also be stdout or stderr. Log output is disabled by default now, which makes it more feasible to add more log statements to trace program flow in debugging situations.
Fixed bug where manually specifying port 443 disabled TLS (whoops); otherHostHasScheme was the culprit, since it would return true even if it was the same config that had that scheme.
Also, an error at startup (if not a restart) is now fatal, rather than keeping a half-alive zombie server.
By chaining in a middleware handler and using newly exposed hooks from the acme package, we're able to proxy ACME requests on port 443 to the ACME client listening on a different port.
Before, we were activating Let's Encrypt after all the directives were executed. This means their setup functions had access to potentially erroneous information about the server's TLS setup, since the letsencrypt package makes changes to the port, etc. Now, we execute all directives up to and including tls, then activate letsencrypt, then finish with the rest of the directives. It's a bit ugly, but I do think it is more correct. It also fixes some bugs, for example: a host that only has a catch-all redirect.
In testing, I've found that Windows doesn't release the socket right away even though the listener is closed, so calling caddy.Start() right after caddy.Stop() can fail. This change has server.ListenAndServe() try up to 20 times every 100ms to bind the listener, and only return an error if it doesn't succeed after 2 seconds. This might be kind of nifty for Unix, too, but there hasn't been a need for it yet.
The file path of the originally-loaded Caddyfile must be piped to the forked process; previously it was using stdin after the first fork, which wouldn't load the newest Caddyfile from disk, which is the point of SIGUSR1.
OCSP status is checked at a regular interval, and if the OCSP status changes for any of the certificates, the change callback is executed (restarts the server, updating the OCSP staple).
Merged config and app packages into one called caddy. Abstracted away caddy startup functionality making it easier to embed Caddy in any Go application and use it as a library. Graceful restart (should) now ensure child starts properly. Now piping a gob bundle to child process so that the child can match up inherited listeners to server address. Much cleanup still to do.
Lots of refinement still needed and runs only on POSIX systems. Windows will not get true graceful restarts (for now), but we will opt for very, very quick forceful restarts. Also, server configs are no longer put into a map; it is critical that they stay ordered so that they can be matched with their sockets in the child process after forking.
This implementation of graceful restarts is probably not perfect, but it is a good start. Lots of details to attend to now.
These tests with the backslash seem to assert that shlex (our Unix shell parsing library) is working properly, not our wrapper function (that parses commands for both Windows and non-Windows). These tests break on Windows so I have removed them.
This way, Setup functions have access to the list of hosts that share the server block, and also, if needed for some reason, the index of the server block in the input
startup and shutdown commands should only be executed once per appearance in the Caddyfile (naturally meaning once per server block).
Notice that we support multiple occurrences of startup and shutdown in the same server block by building the callback array incrementally as we parse the Caddyfile, then we append all the callbacks all at once. Quite literally, the OncePerServerBlock function executes only once per server block!
If each server block had only one sync.Once then all directives would refer to it and only the first directive would be able to use it! So this commit changes it to a map of sync.Once instances, keyed by directive. So by creating a new map for every server block, each directive in that block can get its own sync.Once which is exactly what is needed. They won't step on each other this way.
Turns out having each server block share a single server.Config during initialization when the Setup functions are being called was a bad idea. Sure, startup and shutdown functions were only executed once, but they had no idea what their hostname or port was. So here we revert to the old way of doing things where Setup may be called multiple times per server block (once per host associated with the block, to be precise), but the Setup functions now know their host and port since the config belongs to exactly one virtualHost. To have something happen just once per server block, use OncePerServerBlock, a new function available on each Controller.
This way, Setup functions have access to the list of hosts that share the server block, and also, if needed for some reason, the index of the server block in the input
startup and shutdown commands should only be executed once per appearance in the Caddyfile (naturally meaning once per server block).
Notice that we support multiple occurrences of startup and shutdown in the same server block by building the callback array incrementally as we parse the Caddyfile, then we append all the callbacks all at once. Quite literally, the OncePerServerBlock function executes only once per server block!
If each server block had only one sync.Once then all directives would refer to it and only the first directive would be able to use it! So this commit changes it to a map of sync.Once instances, keyed by directive. So by creating a new map for every server block, each directive in that block can get its own sync.Once which is exactly what is needed. They won't step on each other this way.
Turns out having each server block share a single server.Config during initialization when the Setup functions are being called was a bad idea. Sure, startup and shutdown functions were only executed once, but they had no idea what their hostname or port was. So here we revert to the old way of doing things where Setup may be called multiple times per server block (once per host associated with the block, to be precise), but the Setup functions now know their host and port since the config belongs to exactly one virtualHost. To have something happen just once per server block, use OncePerServerBlock, a new function available on each Controller.
"A receive from a closed channel returns the zero value immediately"
Close the tickerChan in the calling function, this causes "case <-c" to
unblock immediately, ending the goroutine and stopping the ticker.
NewTestController now sets the site root to '.' to accomodate Windows. This introduced a failure on Linux because we join "." and an absolute path in /tmp/ and end up looking for the temp file in the wrong place. This change puts the temp file under the current working directory, which should resolve the issue.
Most of the Windows test failures are due to the path separator not being "/". The general approach I took here was to keep paths in "URL form" (ie using "/" separators) as much as possible, and only convert to native paths when we attempt to open a file. This will allow the most consistency between different host OS. For example, data structures that store paths still store them with "/" delimiters. Functions that accepted paths as input and return them as outputs still use "/".
There are still a few test failures that need to be sorted out.
- config/setup/TestRoot (I hear this has already been fixed by someone else)
- middleware/basicauth/TestBrowseTemplate and middleware/templates/Test (a line endings issue that I'm still working through)
... I think. Submitting as PR to double-check. This change changes file mod times on the testdata to ensure they are not all the same so that the sort is predictable!
In latest go versions TestWatcher fails pretty often, because it is
"more concurrent" now. Reproducible with go master:
while go test github.com/mholt/caddy/middleware/markdown; do :; done
Signed-off-by: Alexander Morozov <lk4d4@docker.com>
* As value mutex was copied and therefore synchronization worked wrong
* It's pretty big structure with reference types, so copying create unnecessary
pressure on GC
Signed-off-by: Alexander Morozov <lk4d4@docker.com>
The errors and logs can now have log rolling if provided by the user.
The current customisable parameter of it are:
The maximal size of the file before rolling.
The maximal age/time of the file before rolling.
The number of backups to keep.
Even if defined for multiple hosts. Startup or shutdown callbacks registered by any directive (startup, shutdown, markdown, git, log, etc.) will only run as many times as it appears in the Caddyfile, not repeated for each host that shares that server block. Fixing this involved refactoring three packages (yeesh) and we need to restore some tests that are no longer valid (that used to verify splitting a multiServerBlock into multiple serverBlocks).
markdown: Add .Links action and flattened metadata structure
.Links available only for generated sites and variables no longer in a [variables] category in metadata (flat structure).
Created a struct containing middleware.Context, Title, Markdown and the
variables from the user to use to render the template.
The title now can be accessed via {{.Title}}.
The variables can now be accessed via {{.Var.myVariableName}}.
Moved the Context type to middleware and exported it.
Users can use .Include and others in browse directive templating
Created test for the templates directive.
Used http status code instead of a hardcoded value.
Used url.Parse instead of url.ParseRequestURI, so that you can parse
both absolute and relative URL.
Addresses which fail to resolve are handled more gracefully in the two most common cases: the hostname doesn't resolve or the port is unknown (like "http" on a system that doesn't support that port name). If the hostname doesn't resolve, the host is served on the listener at host 0.0.0.0. If the port is unknown, we attempt to rewrite it as a number manually and try again.
Update with missing assertion for the Next middleware being properly set , this makes sure that Ext middleware carries the requests to the further middlewares .
fixes issue with Status header coming from php-fpm 5.5 different then regular "HTTP/1.1 200 OK".
If server returns Status code - "200" will be handled properly instead "throwing runtime error: index out of range"
Proper Location redirects are disadvantageous in some situations.
For example, you may want a developer to know that a resource is available
via https, but you don't want an insecure call to the API to succeed.
The webhook providers reside behind a small interface which determines if
a provider should run. If a provider should run it delegates
responsibility of the request to the provider.
ghdeploy initial commit
Added webhook functionality to the git middleware.
The webhook providers reside behind a small interface which determines if a provider should run. If a provider should run it delegates responsibility of the request to the provider.
Add tests
Remove old implementation
Fix inconsistency with git interval pulling.
Remove '\n' from logging statements and put the initial pull into a startup function
If we do not use a pointer here, the startup function that opens the log file stores the log file in a copy of the handler, not the same instance of the handler, causing panics during requests, which is bad, especially when the response is gzipped: the next recover() is beyond the gzip handler, so the browser downloads a gz file instead.
You can have a huge impact on the project by helping with its code. To contribute code to Caddy, open a [pull request](https://github.com/caddyserver/caddy/pulls) (PR). If you're new to our community, that's okay: **we gladly welcome pull requests from anyone, regardless of your native language or coding experience.** You can get familiar with Caddy's code base by using [code search at Sourcegraph](https://sourcegraph.com/github.com/caddyserver/caddy/-/search).
You can have a direct impact on the project by helping with its code. To contribute code to Caddy, open a [pull request](https://github.com/mholt/caddy/pulls) (PR). If you're new to our community, that's okay: **we gladly welcome pull requests from anyone, regardless of your native language or coding experience.** You can get familiar with Caddy's code base by using [code search at Sourcegraph](https://sourcegraph.com/github.com/mholt/caddy/-/search).
We hold contributions to a high standard for quality :bowtie:, so don't be surprised if we ask for revisions—even if it seems small or insignificant. Please don't take it personally. :blue_heart: If your change is on the right track, we can guide you to make it mergable.
We hold contributions to a high standard for quality :bowtie:, so don't be surprised if we ask for revisions—even if it seems small or insignificant. Please don't take it personally. :wink: If your change is on the right track, we can guide you to make it mergable.
Here are some of the expectations we have of contributors:
- **Open an issue to propose your change first.** This way we can avoid confusion, coordinate what everyone is working on, and ensure that any changes are in-line with the project's goals and the best interests of its users. We can also discuss the best possible implementation. If there's already an issue about it, comment on the existing issue to claim it.
-If your change is more than just a minor alteration, **open an issue to propose your change first.** This way we can avoid confusion, coordinate what everyone is working on, and ensure that changes are in-line with the project's goals and the best interests of its users. If there's already an issue about it, comment on the existing issue to claim it.
- **Keep pull requests small.** Smaller PRs are more likely to be merged because they are easier to review! We might ask you to break up large PRs into smaller ones. [An example of what we want to avoid.](https://twitter.com/iamdevloper/status/397664295875805184)
- **Keep pull requests small.** Smaller PRs are more likely to be merged because they are easier to review! We might ask you to break up large PRs into smaller ones. [An example of what we DON'T do.](https://twitter.com/iamdevloper/status/397664295875805184)
- **Keep related commits together in a PR.** We do want pull requests to be small, but you should also keep multiple related commits in the same PR if they rely on each other.
@@ -52,26 +52,26 @@ We often grant [collaborator status](#collaborator-instructions) to contributors
Contributing to Go projects on GitHub is fun and easy. We recommend the following workflow:
1. [Fork this repo](https://github.com/caddyserver/caddy). This makes a copy of the code you can write to.
1. [Fork this repo](https://github.com/mholt/caddy). This makes a copy of the code you can write to.
2. If you don't already have this repo (caddyserver/caddy.git) repo on your computer, get it with `go get github.com/caddyserver/caddy/v2`.
2. If you don't already have this repo (mholt/caddy.git) repo on your computer, get it with `go get github.com/mholt/caddy/caddy`.
3. Tell git that it can push the caddyserver/caddy.git repo to your fork by adding a remote: `git remote add myfork https://github.com/<your-username>/caddy.git`
3. Tell git that it can push the mholt/caddy.git repo to your fork by adding a remote: `git remote add myfork https://github.com/you/caddy.git`
4. Make your changes in the caddyserver/caddy.git repo on your computer.
4. Make your changes in the mholt/caddy.git repo on your computer.
5. Push your changes to your fork: `git push myfork`
6. [Create a pull request](https://github.com/caddyserver/caddy/pull/new/master) to merge your changes into caddyserver/caddy @ master. (Click "compare across forks" and change the head fork.)
6. [Create a pull request](https://github.com/mholt/caddy/pull/new/master) to merge your changes into mholt/caddy @ master. (Click "compare across forks" and change the head fork.)
This workflow is nice because you don't have to change import paths. You can get fancier by using different branches if you want.
### Writing a Caddy module
### Writing a plugin
Caddy can do more with modules! Anyone can write one. Caddy modules are Go libraries that get compiled into Caddy, extending its feature set. They can add directives to the Caddyfile, add new configuration adapters, and even implement new server types (e.g. HTTP, DNS).
Caddy can do more with plugins! Anyone can write a plugin. Plugins are Go libraries that get compiled into Caddy, extending its feature set. They can add directives to the Caddyfile, change how the Caddyfile is loaded, and even implement new server types (e.g. HTTP, DNS). When it's ready, you can submit your plugin to the Caddy website so others can download it.
[Learn how to write a module here](https://caddyserver.com/docs/extending-caddy). You should also share and discuss your module idea [on the forums](https://caddy.community) to have people test it out. We don't use the Caddy issue tracker for third-party modules.
[Learn how to write and submit a plugin](https://github.com/mholt/caddy/wiki) on the wiki. You should also share and discuss your plugin idea [on the forums](https://caddy.community) to have people test it out. We don't use the Caddy issue tracker for plugins.
### Getting help using Caddy
@@ -83,7 +83,7 @@ Many people on the forums could benefit from your experience and expertise, too.
### Reporting bugs
Like every software, Caddy has its flaws. If you find one, [search the issues](https://github.com/caddyserver/caddy/issues) to see if it has already been reported. If not, [open a new issue](https://github.com/caddyserver/caddy/issues/new) and describe the bug, and somebody will look into it! (This repository is only for Caddy and its standard modules.)
Like every software, Caddy has its flaws. If you find one, [search the issues](https://github.com/mholt/caddy/issues) to see if it has already been reported. If not, [open a new issue](https://github.com/mholt/caddy/issues/new) and describe the bug, and somebody will look into it! (This repository is only for Caddy, not plugins.)
**You can help stop bugs in their tracks!** Speed up the patch by identifying the bug in the code. This can sometimes be done by adding `fmt.Println()` statements (or similar) in relevant code paths to narrow down where the problem may be. It's a good way to [introduce yourself to the Go language](https://tour.golang.org), too.
@@ -93,50 +93,25 @@ We suggest reading [How to Report Bugs Effectively](http://www.chiark.greenend.o
Please be kind. :smile: Remember that Caddy comes at no cost to you, and you're getting free support when we fix your issues. If we helped you, please consider helping someone else!
#### Bug reporting expectations
Maintainers---or more generally, developers---need three things to act on bugs:
1. To agree or be convinced that it's a bug (reporter's responsibility).
- A bug is undesired or surprising behavior which violates documentation or the spec.
2. To be able to understand what is happening (mostly reporter's responsibility).
- If the reporter can provide satisfactory instructions such that a developer can reproduce the bug, the developer will likely be able to understand the bug, write a test case, and implement a fix.
- Otherwise, the burden is on the reporter to test possible solutions. This is discouraged because it loosens the feedback loop, slows down debugging efforts, obscures the true nature of the problem from the developers, and is unlikely to result in new test cases.
3. A solution, or ideas toward a solution (mostly maintainer's responsibility).
- Sometimes the best solution is a documentation change.
- Usually the developers have the best domain knowledge for inventing a solution, but reporters may have ideas or preferences for how they would like the software to work.
- Security, correctness, and project goals/vision all take priority over a user's preferences.
- It's simply good business to yield a solution that satisfies the users, and it's even better business to leave them impressed.
Thus, at the very least, the reporter is expected to:
1. Convince the reader that it's a bug (if it's not obvious).
2. Reduce the problem down to the minimum specific steps required to reproduce it.
The maintainer is usually able to do the rest; but of course the reporter may invest additional effort to speed up the process.
### Suggesting features
First, [search to see if your feature has already been requested](https://github.com/caddyserver/caddy/issues). If it has, you can add a :+1: reaction to vote for it. If your feature idea is new, open an issue to request the feature. Please describe your idea thoroughly so that we know how to implement it! Really vague requests may not be helpful or actionable and, without clarification, will have to be closed.
First, [search to see if your feature has already been requested](https://github.com/mholt/caddy/issues). If it has, you can add a :+1: reaction to vote for it. If your feature idea is new, open an issue to request the feature. You don't have to follow the bug template for feature requests. Please describe your idea thoroughly so that we know how to implement it! Really vague requests may not be helpful or actionable and without clarification will have to be closed.
While we really do value your requests and implement many of them, not all features are a good fit for Caddy. Most of those [make good modules](#writing-a-caddy-module), which can be made by anyone! But if a feature is not in the best interest of the Caddy project or its users in general, we may politely decline to implement it into Caddy core.
While we really do value your requests and implement many of them, not all features are a good fit for Caddy. Most of those [make good plugins](https://github.com/mholt/caddy/wiki), though, which can be made by anyone! But if a feature is not in the best interest of the Caddy project or its users in general, we may politely decline to implement it into Caddy core.
### Improving documentation
Caddy's documentation is available at [https://caddyserver.com/docs](https://caddyserver.com/docs) and its source is in the [website repo](https://github.com/caddyserver/website). If you would like to make a fix to the docs, please submit an issue there describing the change to make.
Caddy's documentation is available at [https://caddyserver.com/docs](https://caddyserver.com/docs). If you would like to make a fix to the docs, feel free to contribute at the [caddyserver/website](https://github.com/caddyserver/website) repository!
Note that third-party module documentation is not hosted by the Caddy website, other than basic usage examples. They are managed by the individual module authors, and you will have to contact them to change their documentation.
Note that plugin documentation is not hosted by the Caddy website, other than basic usage examples. They are managed by the individual plugin authors, and you will have to contact them to change their documentation.
## Collaborator Instructions
Collaborators have push rights to the repository. We grant this permission after one or more successful, high-quality PRs are merged! We thank them for their help.The expectations we have of collaborators are:
Collabators have push rights to the repository. We grant this permission after one or more successful, high-quality PRs are merged! We thank them for their help.The expectations we have of collaborators are:
- **Help review pull requests.** Be meticulous, but also kind. We love our contributors, but we critique the contribution to make it better. Multiple, thorough reviews make for the best contributions! Here are some questions to consider:
- Can the change be made more elegant?
@@ -153,9 +128,9 @@ Collaborators have push rights to the repository. We grant this permission after
- **Prefer squashed commits over a messy merge.** If there are many little commits, please [squash the commits](https://stackoverflow.com/a/11732910/1048862) so we don't clutter the commit history.
- **Don't accept new dependencies lightly.** Dependencies can make the world crash and burn, but they are sometimes necessary. Choose carefully. Extremely small dependencies (a few lines of code) can be inlined. The rest may not be needed. For those that are, Caddy uses [go modules](https://github.com/golang/go/wiki/Modules). All external dependencies must be installed as modules, and _Caddy must not export any types defined by those dependencies_. Check this diligently!
- **Don't accept new dependencies lightly.** Dependencies can make the world crash and burn, but they are sometimes necessary. Choose carefully. Extremely small dependencies (a few lines of code) can be inlined. The rest may not be needed. For those that are, Caddy vendors all dependencies with the help of [gvt](https://github.com/FiloSottile/gvt). All external dependencies must be vendored, and _Caddy must not export any types defined by those dependencies_. Check this diligently!
- **Be extra careful in some areas of the code.** There are some critical areas in the Caddy code base that we review extra meticulously: the `caddyhttp` and `caddytls` packages especially.
- **Be extra careful in some areas of the code.** There are some critical areas in the Caddy code base that we review extra meticulously: the `caddy` and `caddytls` packages especially.
- **Make sure tests test the actual thing.** Double-check that the tests fail without the change, and pass with it. It's important that they assert what they're purported to assert.
@@ -174,11 +149,12 @@ Collaborators have push rights to the repository. We grant this permission after
- The ends justify the means, if the means are good. A good tree won't produce bad fruit. But if we cut corners or are hasty in our process, the end result will not be good.
## Security Policy
## Responsible Disclosure
If you think you've found a security vulnerability, please refer to our [Security Policy](https://github.com/caddyserver/caddy/security/policy) document.
If you've found a security vulnerability, please email me, the author, directly: Matthew dot Holt at Gmail. I'll need enough information to verify the bug and make a patch. It will speed things up if you suggest a working patch. If your report is valid and a patch is released, we will not reveal your identity by default. If you wish to be credited, please give me the name to use. Thanks for responsibly helping Caddy—and thousands of websites—be more secure!
## Thank you
Thanks for your help! Caddy would not be what it is today without your contributions.
Thanks for your help! Caddy would not be what it is today without your
Are you asking for help with using Caddy? Please use our forum instead: https://caddy.community. If you are filing a bug report, please take a few minutes to carefully answer the following questions. If your issue is not a bug report, you do not need to use this template. Thanks!)
-->
### 1. What version of Caddy are you using (`caddy -version`)?
### 2. What are you trying to do?
### 3. What is your entire Caddyfile?
```text
(paste Caddyfile here)
```
### 4. How did you run Caddy (give the full command and describe the execution environment)?
### 5. Please paste any relevant HTTP request(s) here.
<!-- Paste curl command, or full HTTP request including headers and body, here. -->
### 6. What did you expect to see?
### 7. What did you see instead (give full error messages and/or log)?
### 8. How can someone who is starting from scratch reproduce the bug as minimally as possible?
<!-- Please strip away any extra infrastructure such as containers, reverse proxies, upstream apps, caches, dependencies, etc, to prove this is a bug in Caddy and not an external misconfiguration. Your chances of getting this bug fixed go way up the easier it is to replicate. Thank you! -->
The Caddy project would like to make sure that it stays on top of all practically-exploitable vulnerabilities.
Some security problems are more the result of interplay between different components of the Web, rather than a vulnerability in the web server itself. Please report only vulnerabilities in the web server itself, as we cannot coerce the rest of the Web to be fixed (for example, we do not consider IP spoofing or BGP hijacks a vulnerability in the Caddy web server).
Please note that we consider publicly-registered domain names to be public information. This necessary in order to maintain the integrity of certificate transparency, public DNS, and other public trust systems.
## Supported Versions
| Version | Supported |
| ------- | ------------------ |
| 2.x | :white_check_mark: |
| 1.x | :x: |
| < 1.x | :x: |
## Reporting a Vulnerability
Please email Matt Holt (the author) directly: matt [at] lightcodelabs [dot com].
We'll need enough information to verify the bug and make a patch. It will speed things up if you suggest a working patch, such as a code diff, and explain why and how it works. Reports that are not actionable, do not contain enough information, are too pushy/demanding, or are not able to convince us that it is a viable and practical attack on the web server itself may be deferred to a later time or possibly ignored, resources permitting. Priority will be given to credible, responsible reports that are constructive, specific, and actionable. Thank you for understanding.
Please also understand that due to our nature as an open source project, we do not have a budget to award security bounties. We can only thank you.
If your report is valid and a patch is released, we will not reveal your identity by default. If you wish to be credited, please give us the name to use and/or your GitHub username. If you don't provide this we can't credit you.
Thanks for responsibly helping Caddy—and thousands of websites—be more secure!
<a href="https://twitter.com/caddyserver" title="@caddyserver on Twitter"><img src="https://img.shields.io/badge/twitter-@caddyserver-55acee.svg" alt="@caddyserver on Twitter"></a>
<a href="https://sourcegraph.com/github.com/caddyserver/caddy?badge" title="Caddy on Sourcegraph"><img src="https://sourcegraph.com/github.com/caddyserver/caddy/-/badge.svg" alt="Caddy on Sourcegraph"></a>
<a href="https://sourcegraph.com/github.com/mholt/caddy?badge" title="Caddy on Sourcegraph"><img src="https://sourcegraph.com/github.com/mholt/caddy/-/badge.svg" alt="Caddy on Sourcegraph"></a>
- **Easy configuration** with the [Caddyfile](https://caddyserver.com/docs/caddyfile)
-**Powerful configuration** with its [native JSON config](https://caddyserver.com/docs/json/)
-**Dynamic configuration** with the [JSON API](https://caddyserver.com/docs/api)
-[**Config adapters**](https://caddyserver.com/docs/config-adapters) if you don't like JSON
- **Automatic HTTPS** by default
- [ZeroSSL](https://zerossl.com) and [Let's Encrypt](https://letsencrypt.org) for public names
- Fully-managed local CA for internal names & IPs
- Can coordinate with other Caddy instances in a cluster
- Multi-issuer fallback
- **Stays up when other servers go down** due to TLS/OCSP/certificate-related issues
- **Production-ready** after serving trillions of requests and managing millions of TLS certificates
- **Scales to tens of thousands of sites** ... and probably more
- **HTTP/1.1, HTTP/2, and experimental HTTP/3** support
- **Highly extensible** [modular architecture](https://caddyserver.com/docs/architecture) lets Caddy do anything without bloat
- **Easy configuration** with the Caddyfile
- **Automatic HTTPS** on by default (via [Let's Encrypt](https://letsencrypt.org))
- **HTTP/2** by default
- **Virtual hosting** so multiple sites just work
-Experimental **QUIC support** for cutting-edge transmissions
-TLS session ticket **key rotation** for more secure connections
-**Extensible with plugins** because a convenient web server is a helpful one
- **Runs anywhere** with **no external dependencies** (not even libc)
- Written in Go, a language with higher **memory safety guarantees** than other servers
- Actually **fun to use**
- So, so much more to [discover](https://caddyserver.com/v2)
[See a more complete list of features built into Caddy.](https://caddyserver.com/features) On top of all those, Caddy does even more with plugins: choose which plugins you want at [download](https://caddyserver.com/download).
Altogether, Caddy can do things other web servers simply cannot do. Its features and plugins save you time and mistakes, and will cheer you up. Your Caddy instance takes care of the details for you!
## Install
The simplest, cross-platform way is to download from [GitHub Releases](https://github.com/caddyserver/caddy/releases) and place the executable file in your PATH.
Caddy binaries have no dependencies and are available for every platform. Get Caddy either of these ways:
For other install options, see https://caddyserver.com/docs/download.
- **[Download page](https://caddyserver.com/download)** (RECOMMENDED) allows you to customize your build in the browser
- **[Latest release](https://github.com/mholt/caddy/releases/latest)** for pre-built, vanilla binaries
## Build from source
Requirements:
## Build
- [Go 1.14 or newer](https://golang.org/dl/)
To build from source you need **[Git](https://git-scm.com/downloads)** and **[Go](https://golang.org/doc/install)** (1.9 or newer). Follow these instruction for fast building:
### For development
_**Note:** These steps [will not embed proper version information](https://github.com/golang/go/issues/29228). For that, please follow the instructions in the next section._
- Get the source with `go get github.com/mholt/caddy/caddy` and then run `go get github.com/caddyserver/builds`
- Now `cd $GOPATH/src/github.com/mholt/caddy/caddy` and run `go run build.go`
Then make sure the `caddy` binary is in your PATH.
When you run Caddy, it may try to bind to low ports unless otherwise specified in your config. If your OS requires elevated privileges, you will need to give your new binary permission to do so. On Linux, this can be done easily with: `sudo setcap cap_net_bind_service=+ep ./caddy`
To build for other platforms, use build.go with the `--goos` and `--goarch` flags.
If you prefer to use `go run` which creates temporary binaries, you can still do this. Make an executable file called `setcap.sh` (or whatever you want) with these contents:
```bash
#!/bin/sh
sudo setcap cap_net_bind_service=+ep "$1"
"$@"
```
## Quick Start
then you can use `go run` like so:
```bash
$ go run -exec ./setcap.sh main.go
```
If you don't want to type your password for `setcap`, use `sudo visudo` to edit your sudoers file and allow your user account to run that command without a password, for example:
To serve static files from the current working directory, run:
```
username ALL=(ALL:ALL) NOPASSWD: /usr/sbin/setcap
caddy
```
replacing `username` with your actual username. Please be careful and only do this if you know what you are doing! We are only qualified to document how to use Caddy, not Go tooling or your computer, and we are providing these instructions for convenience only; please learn how to use your own computer at your own risk and make any needful adjustments.
Caddy's default port is 2015, so open your browser to [http://localhost:2015](http://localhost:2015).
### With version information and/or plugins
### Go from 0 to HTTPS in 5 seconds
Using [our builder tool, `xcaddy`](https://github.com/caddyserver/xcaddy)...
If the `caddy` binary has permission to bind to low ports and your domain name's DNS records point to the machine you're on:
```
$ xcaddy build
caddy -host example.com
```
...the following steps are automated:
This command serves static files from the current directory over HTTPS. Certificates are automatically obtained and renewed for you! Caddy is also automatically configuring ports 80 and 443 for you, and redirecting HTTP to HTTPS. Cool, huh?
1. Create a new folder: `mkdir caddy`
2. Change into it: `cd caddy`
3. Copy [Caddy's main.go](https://github.com/caddyserver/caddy/blob/master/cmd/caddy/main.go) into the empty folder. Add imports for any custom plugins you want to add.
4. Initialize a Go module: `go mod init caddy`
5. (Optional) Pin Caddy version: `go get github.com/caddyserver/caddy/v2@version` replacing `version` with a git tag or commit.
6. (Optional) Add plugins by adding their import: `_ "import/path/here"`
7. Compile: `go build`
### Customizing your site
To customize how your site is served, create a file named Caddyfile by your site and paste this into it:
```plain
localhost
push
browse
websocket /echo cat
ext .html
log /var/log/access.log
proxy /api 127.0.0.1:7005
header /api Access-Control-Allow-Origin *
```
When you run `caddy` in that directory, it will automatically find and use that Caddyfile.
This simple file enables server push (via Link headers), allows directory browsing (for folders without an index file), hosts a WebSocket echo server at /echo, serves clean URLs, logs requests to an access log, proxies all API requests to a backend on port 7005, and adds the coveted `Access-Control-Allow-Origin: *` header for all responses from the API.
Wow! Caddy can do a lot with just a few lines.
### Doing more with Caddy
To host multiple sites and do more with the Caddyfile, please see the [Caddyfile tutorial](https://caddyserver.com/tutorial/caddyfile).
Sites with qualifying hostnames are served over [HTTPS by default](https://caddyserver.com/docs/automatic-https).
Caddy has a nice little command line interface. Run `caddy -h` to view basic help or see the [CLI documentation](https://caddyserver.com/docs/cli) for details.
## Running in Production
Caddy is production-ready if you find it to be a good fit for your site and workflow.
**Running as root:** We advise against this. You can still listen on ports < 1024 on Linux using setcap like so: `sudo setcap cap_net_bind_service=+ep ./caddy`
The Caddy project does not officially maintain any system-specific integrations nor suggest how to administer your own system. But your download file includes [unofficial resources](https://github.com/mholt/caddy/tree/master/dist/init) contributed by the community that you may find helpful for running Caddy in production.
How you choose to run Caddy is up to you. Many users are satisfied with `nohup caddy &`. Others use `screen`. Users who need Caddy to come back up after reboots either do so in the script that caused the reboot, add a command to an init script, or configure a service with their OS.
If you have questions or concerns about Caddy' underlying crypto implementations, consult Go's [crypto packages](https://golang.org/pkg/crypto), starting with their documentation, then issues, then the code itself; as Caddy uses mainly those libraries.
## Quick start
## Contributing
The [Caddy website](https://caddyserver.com/docs/) has documentation that includes tutorials, quick-start guides, reference, and more.
**[Join our forum](https://caddy.community) where you can chat with other Caddy users and developers!** To get familiar with the code base, try [Caddy code search on Sourcegraph](https://sourcegraph.com/github.com/mholt/caddy/-/search)!
**We recommend that all users -- regardless of experience level -- do our [Getting Started](https://caddyserver.com/docs/getting-started) guide to become familiar with using Caddy.**
Please see our [contributing guidelines](https://github.com/mholt/caddy/blob/master/.github/CONTRIBUTING.md) for instructions. If you want to write a plugin, check out the [developer wiki](https://github.com/mholt/caddy/wiki).
If you've only got a minute, [the website has several quick-start tutorials](https://caddyserver.com/docs/quick-starts) to choose from! However, after finishing a quick-start tutorial, please read more documentation to understand how the software works. 🙂
We use GitHub issues and pull requests only for discussing bug reports and the development of specific changes. We welcome all other topics on the [forum](https://caddy.community)!
If you want to contribute to the documentation, please submit pull requests to [caddyserver/website](https://github.com/caddyserver/website).
Thanks for making Caddy -- and the Web -- better!
## Donors
- [DigitalOcean](https://m.do.co/c/6d7bdafccf96) is hosting the Caddy project.
- [DNSimple](https://dnsimple.link/resolving-caddy) provides DNS services for Caddy's sites.
- [DNS Spy](https://dnsspy.io) keeps an eye on Caddy's DNS properties.
We thank them for their services. **If you want to help keep Caddy free, please [become a sponsor](https://caddyserver.com/pricing)!**
## Overview
## About the Project
Caddy is most often used as an HTTPS server, but it is suitable for any long-running Go program. First and foremost, it is a platform to run Go applications. Caddy "apps" are just Go programs that are implemented as Caddy modules. Two apps -- `tls` and `http` -- ship standard with Caddy.
Caddy was born out of the need for a "batteries-included" web server that runs anywhere and doesn't have to take its configuration with it. Caddy took inspiration from [spark](https://github.com/rif/spark), [nginx](https://github.com/nginx/nginx), lighttpd,
[Websocketd](https://github.com/joewalnes/websocketd) and [Vagrant](https://www.vagrantup.com/), which provides a pleasant mixture of features from each of them.
Caddy apps instantly benefit from [automated documentation](https://caddyserver.com/docs/json/), graceful on-line [config changes via API](https://caddyserver.com/docs/api), and unification with other Caddy apps.
**The name "Caddy" is trademarked:** The name of the software is "Caddy", not "Caddy Server" or "CaddyServer". Please call it "Caddy" or, if you wish to clarify, "the Caddy web server". See [brand guidelines](https://caddyserver.com/brand). Caddy is a registered trademark of Light Code Labs, LLC.
Although [JSON](https://caddyserver.com/docs/json/) is Caddy's native config language, Caddy can accept input from [config adapters](https://caddyserver.com/docs/config-adapters) which can essentially convert any config format of your choice into JSON: Caddyfile, JSON 5, YAML, TOML, NGINX config, and more.
The primary way to configure Caddy is through [its API](https://caddyserver.com/docs/api), but if you prefer config files, the [command-line interface](https://caddyserver.com/docs/command-line) supports those too.
Caddy exposes an unprecedented level of control compared to any web server in existence. In Caddy, you are usually setting the actual values of the initialized types in memory that power everything from your HTTP handlers and TLS handshakes to your storage medium. Caddy is also ridiculously extensible, with a powerful plugin system that makes vast improvements over other web servers.
To wield the power of this design, you need to know how the config document is structured. Please see [our documentation site](https://caddyserver.com/docs/) for details about [Caddy's config structure](https://caddyserver.com/docs/json/).
Nearly all of Caddy's configuration is contained in a single config document, rather than being scattered across CLI flags and env variables and a configuration file as with other web servers. This makes managing your server config more straightforward and reduces hidden variables/factors.
## Full documentation
Our website has complete documentation:
**https://caddyserver.com/docs/**
The docs are also open source. You can contribute to them here: https://github.com/caddyserver/website
## Getting help
- We **strongly recommend** that all professionals or companies using Caddy get a support contract through [Ardan Labs](https://www.ardanlabs.com/my/contact-us?dd=caddy) before help is needed.
- A [sponsorship](https://github.com/sponsors/mholt) goes a long way!
- Individuals can exchange help for free on our community forum at https://caddy.community. Remember that people give help out of their spare time and good will. The best way to get help is to give it first!
Please use our [issue tracker](https://github.com/caddyserver/caddy/issues) only for bug reports and feature requests, i.e. actionable development items (support questions will usually be referred to the forums).
## About
**The name "Caddy" is trademarked.** The name of the software is "Caddy", not "Caddy Server" or "CaddyServer". Please call it "Caddy" or, if you wish to clarify, "the Caddy web server". Caddy is a registered trademark of apilayer GmbH.
- _Project on Twitter: [@caddyserver](https://twitter.com/caddyserver)_
- _Author on Twitter: [@mholt6](https://twitter.com/mholt6)_
Caddy is a project of [ZeroSSL](https://zerossl.com), an [apilayer](https://apilayer.com) company.
*Author on Twitter: [@mholt6](https://twitter.com/mholt6)*
// directives which return a literal subroute instead of a route
// means they intend to keep those handlers together without
// them being reordered; we're doing that anyway since we're in
// the route directive, so just append its handlers
sr.Routes=append(sr.Routes,handler.Routes...)
default:
returnnil,h.Errf("%s directive returned something other than an HTTP route or subroute: %#v (only handler directives can be used in routes)",result.directive,result.Value)
*warnings=append(*warnings,caddyconfig.Warning{Message:"the 'experimental_http3' global option is deprecated, please use the 'servers > protocol > experimental_http3' option instead"})
returnnil,warnings,fmt.Errorf("automation policy from site block is also default/catch-all policy because of key without hostname, and the two are in conflict: %#v != %#v",ap.Issuers,issuers)
}
}
// custom bind host
for_,cfgVal:=rangesblock.pile["bind"]{
for_,iss:=rangeap.Issuers{
// if an issuer was already configured and it is NOT an ACME issuer,
// skip, since we intend to adjust only ACME issuers; ensure we
// include any issuer that embeds/wraps an underlying ACME issuer
varacmeIssuer*caddytls.ACMEIssuer
ifacmeWrapper,ok:=iss.(acmeCapable);ok{
acmeIssuer=acmeWrapper.GetACMEIssuer()
}
ifacmeIssuer==nil{
continue
}
// proceed to configure the ACME issuer's bind host, without
// first make sure this block is allowed to create an automation policy;
// doing so is forbidden if it has a key with no host (i.e. ":443")
// and if there is a different server block that also has a key with no
// host -- since a key with no host matches any host, we need its
// associated automation policy to have an empty Subjects list, i.e. no
// host filter, which is indistinguishable between the two server blocks
// because automation is not done in the context of a particular server...
// this is an example of a poor mapping from Caddyfile to JSON but that's
// the least-leaky abstraction I could figure out
iflen(sblockHosts)==0{
ifserverBlocksWithTLSHostlessKey>1{
// this server block and at least one other has a key with no host,
// making the two indistinguishable; it is misleading to define such
// a policy within one server block since it actually will apply to
// others as well
returnnil,warnings,fmt.Errorf("cannot make a TLS automation policy from a server block that has a host-less address when there are other TLS-enabled server block addresses lacking a host")
}
ifcatchAllAP==nil{
// this server block has a key with no hosts, but there is not yet
// a catch-all automation policy (probably because no global options
// were set), so this one becomes it
catchAllAP=ap
}
}
// associate our new automation policy with this server block's hosts
ap.Subjects=sblockHosts
sort.Strings(ap.Subjects)// solely for deterministic test results
// if a combination of public and internal names were given
// for this same server block and no issuer was specified, we
// need to separate them out in the automation policies so
// that the internal names can use the internal issuer and
// the other names can use the default/public/ACME issuer
varap2*caddytls.AutomationPolicy
iflen(ap.Issuers)==0{
varinternal,external[]string
for_,s:=rangeap.Subjects{
if!certmagic.SubjectQualifiesForCert(s){
returnnil,warnings,fmt.Errorf("subject does not qualify for certificate: '%s'",s)
}
// we don't use certmagic.SubjectQualifiesForPublicCert() because of one nuance:
// names like *.*.tld that may not qualify for a public certificate are actually
// fine when used with OnDemand, since OnDemand (currently) does not obtain
// wildcards (if it ever does, there will be a separate config option to enable
// it that we would need to check here) since the hostname is known at handshake;
// and it is unexpected to switch to internal issuer when the user wants to get
// regular certificates on-demand for a class of certs like *.*.tld.
ap.Issuers=[]certmagic.Issuer{acme,zerossl}// TODO: keep this in sync with Caddy's other issuer defaults elsewhere, like in caddytls/automation.go (DefaultIssuers).
// if a non-ZeroSSL endpoint is specified, we assume we can't use the ZeroSSL issuer successfully
// if there are no global options related to automation policies
// set, then we can just return right away
if!hasGlobalAutomationOpts{
ifalways{
returnnew(caddytls.AutomationPolicy),nil
}
returnnil,nil
}
ap:=new(caddytls.AutomationPolicy)
ifhasKeyType{
ap.KeyType=keyType.(string)
}
ifhasIssuer&&hasLocalCerts{
returnnil,fmt.Errorf("global options are ambiguous: local_certs is confusing when combined with cert_issuer, because local_certs is also a specific kind of issuer")
<ahref="?sort=namedirfirst&order=desc{{if ne 0 .Limit}}&limit={{.Limit}}{{end}}{{if ne 0 .Offset}}&offset={{.Offset}}{{end}}"class="icon"><svgwidth="1em"height=".5em"version="1.1"viewBox="0 0 12.922194 6.0358899"><usexlink:href="#up-arrow"></use></svg></a>
<ahref="?sort=namedirfirst&order=desc{{if ne 0 .ItemsLimitedTo}}&limit={{.ItemsLimitedTo}}{{end}}"class="icon"><svgwidth="1em"height=".5em"version="1.1"viewBox="0 0 12.922194 6.0358899"><usexlink:href="#up-arrow"></use></svg></a>
<ahref="?sort=namedirfirst&order=asc{{if ne 0 .Limit}}&limit={{.Limit}}{{end}}{{if ne 0 .Offset}}&offset={{.Offset}}{{end}}"class="icon"><svgwidth="1em"height=".5em"version="1.1"viewBox="0 0 12.922194 6.0358899"><usexlink:href="#down-arrow"></use></svg></a>
<ahref="?sort=namedirfirst&order=asc{{if ne 0 .ItemsLimitedTo}}&limit={{.ItemsLimitedTo}}{{end}}"class="icon"><svgwidth="1em"height=".5em"version="1.1"viewBox="0 0 12.922194 6.0358899"><usexlink:href="#down-arrow"></use></svg></a>
{{-else}}
<ahref="?sort=namedirfirst&order=asc{{if ne 0 .Limit}}&limit={{.Limit}}{{end}}{{if ne 0 .Offset}}&offset={{.Offset}}{{end}}"class="icon sort"><svgclass="top"width="1em"height=".5em"version="1.1"viewBox="0 0 12.922194 6.0358899"><usexlink:href="#up-arrow"></use></svg><svgclass="bottom"width="1em"height=".5em"version="1.1"viewBox="0 0 12.922194 6.0358899"><usexlink:href="#down-arrow"></use></svg></a>
<ahref="?sort=name&order=desc{{if ne 0 .Limit}}&limit={{.Limit}}{{end}}{{if ne 0 .Offset}}&offset={{.Offset}}{{end}}">Name<svgwidth="1em"height=".5em"version="1.1"viewBox="0 0 12.922194 6.0358899"><usexlink:href="#up-arrow"></use></svg></a>
<ahref="?sort=name&order=desc{{if ne 0 .ItemsLimitedTo}}&limit={{.ItemsLimitedTo}}{{end}}">Name<svgwidth="1em"height=".5em"version="1.1"viewBox="0 0 12.922194 6.0358899"><usexlink:href="#up-arrow"></use></svg></a>
{{-elseifand(eq.Sort"name")(ne.Order"asc")}}
<ahref="?sort=name&order=asc{{if ne 0 .Limit}}&limit={{.Limit}}{{end}}{{if ne 0 .Offset}}&offset={{.Offset}}{{end}}">Name<svgwidth="1em"height=".5em"version="1.1"viewBox="0 0 12.922194 6.0358899"><usexlink:href="#down-arrow"></use></svg></a>
<ahref="?sort=name&order=asc{{if ne 0 .ItemsLimitedTo}}&limit={{.ItemsLimitedTo}}{{end}}">Name<svgwidth="1em"height=".5em"version="1.1"viewBox="0 0 12.922194 6.0358899"><usexlink:href="#down-arrow"></use></svg></a>
{{-else}}
<ahref="?sort=name&order=asc{{if ne 0 .Limit}}&limit={{.Limit}}{{end}}{{if ne 0 .Offset}}&offset={{.Offset}}{{end}}">Name</a>
<ahref="?sort=name&order=asc{{if ne 0 .ItemsLimitedTo}}&limit={{.ItemsLimitedTo}}{{end}}">Name</a>
{{-end}}
</th>
<th>
{{-ifand(eq.Sort"size")(ne.Order"desc")}}
<ahref="?sort=size&order=desc{{if ne 0 .Limit}}&limit={{.Limit}}{{end}}{{if ne 0 .Offset}}&offset={{.Offset}}{{end}}">Size<svgwidth="1em"height=".5em"version="1.1"viewBox="0 0 12.922194 6.0358899"><usexlink:href="#up-arrow"></use></svg></a>
<ahref="?sort=size&order=desc{{if ne 0 .ItemsLimitedTo}}&limit={{.ItemsLimitedTo}}{{end}}">Size<svgwidth="1em"height=".5em"version="1.1"viewBox="0 0 12.922194 6.0358899"><usexlink:href="#up-arrow"></use></svg></a>
{{-elseifand(eq.Sort"size")(ne.Order"asc")}}
<ahref="?sort=size&order=asc{{if ne 0 .Limit}}&limit={{.Limit}}{{end}}{{if ne 0 .Offset}}&offset={{.Offset}}{{end}}">Size<svgwidth="1em"height=".5em"version="1.1"viewBox="0 0 12.922194 6.0358899"><usexlink:href="#down-arrow"></use></svg></a>
<ahref="?sort=size&order=asc{{if ne 0 .ItemsLimitedTo}}&limit={{.ItemsLimitedTo}}{{end}}">Size<svgwidth="1em"height=".5em"version="1.1"viewBox="0 0 12.922194 6.0358899"><usexlink:href="#down-arrow"></use></svg></a>
{{-else}}
<ahref="?sort=size&order=asc{{if ne 0 .Limit}}&limit={{.Limit}}{{end}}{{if ne 0 .Offset}}&offset={{.Offset}}{{end}}">Size</a>
<ahref="?sort=size&order=asc{{if ne 0 .ItemsLimitedTo}}&limit={{.ItemsLimitedTo}}{{end}}">Size</a>
{{-end}}
</th>
<thclass="hideable">
{{-ifand(eq.Sort"time")(ne.Order"desc")}}
<ahref="?sort=time&order=desc{{if ne 0 .Limit}}&limit={{.Limit}}{{end}}{{if ne 0 .Offset}}&offset={{.Offset}}{{end}}">Modified<svgwidth="1em"height=".5em"version="1.1"viewBox="0 0 12.922194 6.0358899"><usexlink:href="#up-arrow"></use></svg></a>
<ahref="?sort=time&order=desc{{if ne 0 .ItemsLimitedTo}}&limit={{.ItemsLimitedTo}}{{end}}">Modified<svgwidth="1em"height=".5em"version="1.1"viewBox="0 0 12.922194 6.0358899"><usexlink:href="#up-arrow"></use></svg></a>
{{-elseifand(eq.Sort"time")(ne.Order"asc")}}
<ahref="?sort=time&order=asc{{if ne 0 .Limit}}&limit={{.Limit}}{{end}}{{if ne 0 .Offset}}&offset={{.Offset}}{{end}}">Modified<svgwidth="1em"height=".5em"version="1.1"viewBox="0 0 12.922194 6.0358899"><usexlink:href="#down-arrow"></use></svg></a>
<ahref="?sort=time&order=asc{{if ne 0 .ItemsLimitedTo}}&limit={{.ItemsLimitedTo}}{{end}}">Modified<svgwidth="1em"height=".5em"version="1.1"viewBox="0 0 12.922194 6.0358899"><usexlink:href="#down-arrow"></use></svg></a>
{{-else}}
<ahref="?sort=time&order=asc{{if ne 0 .Limit}}&limit={{.Limit}}{{end}}{{if ne 0 .Offset}}&offset={{.Offset}}{{end}}">Modified</a>
<ahref="?sort=time&order=asc{{if ne 0 .ItemsLimitedTo}}&limit={{.ItemsLimitedTo}}{{end}}">Modified</a>
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.