* error: run `error` (msg) through replacer
Signed-off-by: Mohammed Al Sahaf <msaa1990@gmail.com>
* fix integration test
Signed-off-by: Mohammed Al Sahaf <msaa1990@gmail.com>
---------
Signed-off-by: Mohammed Al Sahaf <msaa1990@gmail.com>
Most of the errors that can be seen here are write errors due to clients
aborting the request from their side. Often seen ones include:
* writing: ... write: broken pipe
* writing: ... connection timed out
* writing: http2: stream closed
* writing: timeout...
* writing: h3 error...
Most of these errors are beyond of the control of caddy on the client side,
probably nothing can be done on the server side. It still warrants
researching when these errors occur very often, so a change in level from
error to warn is better here to not polute the logs with errors in the
normal case.
* proxyprotocol : Update WrapListener to use ConnPolicyFunc for PROXY protocol support
* proxyprotocol : Updated dependency pires/go-proxyproto to pseudo latest version
* Caddyfile support for TLS handshake matchers:
- caddytls.MatchLocalIP
- caddytls.MatchRemoteIP
- caddytls.MatchServerName
* Caddyfile support for TLS handshake matchers:
- fix imports order
Co-authored-by: Francis Lavoie <lavofr@gmail.com>
---------
Co-authored-by: Francis Lavoie <lavofr@gmail.com>
* Add health_upstream
Signed-off-by: Dylan Schultz <9121234+dylanschultzie@users.noreply.github.com>
* Add health_upstream to caddyfile parsing
* Add Active Upstream case for health checks
* Update ignore health port comment
Signed-off-by: Dylan Schultz <9121234+dylanschultzie@users.noreply.github.com>
* Update Upstream json doc
Signed-off-by: Dylan Schultz <9121234+dylanschultzie@users.noreply.github.com>
* Update modules/caddyhttp/reverseproxy/healthchecks.go
Co-authored-by: Francis Lavoie <lavofr@gmail.com>
* Use error rather than log for health_port override
Signed-off-by: Dylan Schultz <9121234+dylanschultzie@users.noreply.github.com>
* Add comment about port being ignore if using upstream
Signed-off-by: Dylan Schultz <9121234+dylanschultzie@users.noreply.github.com>
---------
Signed-off-by: Dylan Schultz <9121234+dylanschultzie@users.noreply.github.com>
Co-authored-by: Francis Lavoie <lavofr@gmail.com>
* fileserver: Exclude symlink target size from total, show arrow on size
* Keep both totals
* Linter doesn't like my spelling :(
* Stop parallelizing tests for now
* Update modules/caddyhttp/fileserver/browse.html
* Minor renamings
---------
Co-authored-by: Matthew Holt <mholt@users.noreply.github.com>
* caddyhttp: Reject 0-RTT early data in IP matchers and set Early-Data header when proxying
See RFC 8470: https://httpwg.org/specs/rfc8470.html
Thanks to Michael Wedl (@MWedl) at the University of Applied Sciences St. Poelten for reporting this.
* Don't return value for {remote} placeholder in early data
* Add Caddyfile support
101d3e7 introduced a configuration option to set the log file mode.
This option was not taken into account if the file already exists,
making users having to delete their logs to have new logs created
with the right mode.
* Split `run` into a public `BuildContext` and a private part
`BuildContext` can be used to set up a caddy context from a config, but not start any listeners
or active components: The returned context has the configured apps provisioned, but otherwise is
inert.
This is EXPERIMENTAL: Minimally it's missing documentation and the example for how this can be
used to run unit tests.
* Use the config from the context
The config passed into `BuildContext` can be nil, in which case `BuildContext` will just make one
up that works. In either case that will end up in the finished context.
* Rename `BuildContext` to `ProvisionContext` to better match the function
* Hide the `replaceAdminServer` parts
The admin server is a global thing, and in the envisioned use case for `ProvisionContext`
shouldn't actually exist. Hide this detail in a private `provisionContext` instead, and
only expose it publicly with `replaceAdminServer` set to `false`.
This should reduce foot-shooting potential further; in addition the documentation comment
now clearly spells out that the exact interface and implementation details of `ProvisionContext`
are experimental and subject to change.
