Age | Commit message (Collapse) | Author |
|
|
|
|
|
* core: Plugins can register listener networks
This can be useful for custom listeners.
This feature/API is experimental and may change!
* caddyhttp: Expose server listeners
|
|
See comment in #4996
|
|
Co-authored-by: Matt Holt <mholt@users.noreply.github.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* reverseproxy: Add `_ms` placeholders for proxy durations
* Add http.request.duration_ms
Also add comments, and change duration_sec to duration_ms
* Add response.duration_ms for consistency
* Add missing godoc comment
Co-authored-by: Matthew Holt <mholt@users.noreply.github.com>
|
|
|
|
|
|
|
|
* caddyhttp: Reject absurdly long methods
* Limit method to 32 chars and truncate
* Just reject the request and debug-log it
* Log remote address
|
|
Potential fix for #4017 although the consensus is unclear.
Made change to return status code 421 instead of 403 when StrictSNIHost matching is on.
|
|
|
|
|
|
Fixes #4428
It's best to still log handler errors at debug level so that they're hidden by default, but still accessible if additional details are necessary.
|
|
See https://github.com/caddyserver/caddy/issues/4148#issuecomment-833207811
|
|
|
|
* caddyhttp: Implement better logic for inserting the HTTP->HTTPS redirs
* caddyhttp: Add integration test
|
|
|
|
|
|
Before, if there was an error in the error handler, we would not write a
status code, which resulted in Go writing a 200 for us by default, which
does not make sense when there's an error. Now we write the second
error's status if available, otherwise 500.
|
|
|
|
* caddyhttp: Restore original request params before error handlers
Fixes #3717
* Add comment
|
|
* metrics: Fixing panic while observing with bad exemplars
Signed-off-by: Dave Henderson <dhenderson@gmail.com>
* Minor cleanup
The server is already added to the context. So, we can simply use that
to get the server name, which is a field on the server.
* Add integration test for auto HTTP->HTTPS redirects
A test like this would have caught the problem in the first place
Co-authored-by: Matthew Holt <mholt@users.noreply.github.com>
|
|
First try an exact lookup like before, but if it fails, strip the port
and try again. example.com:1234 should still use a logger keyed for
example.com if there is no key example.com:1234.
|
|
* adding wildcard matching of logger names
* reordering precedence for more specific loggers to match first
* removing dependence on certmagic and extra loop
Co-authored-by: GregoryDosh <GregoryDosh@users.noreply.github.com>
|
|
While building a layer4 app for Caddy, I discovered that we need the
ability to fill a request's context just like the HTTP server does,
hence this exported function PrepareRequest().
|
|
* reverse_proxy: Initial attempt at H2C transport/client support (#3218)
I have not tested this yet
* Experimentally enabling H2C server support (closes #3227)
See also #3218
I have not tested this
* reverseproxy: Clean up H2C transport a bit
* caddyhttp: Update godoc for h2c server; clarify experimental status
* caddyhttp: Fix trailers when recording responses (fixes #3236)
* caddyhttp: Tweak h2c config settings and docs
|
|
Also un-nest all the error handling, that was unnecessary indentation
|
|
* httpcaddyfile: Exclude access logs written to files from default log
Even though any logs can just be ignored, most users don't seem to like
configuring an access log to go to a file only to have it doubly appear
in the default log.
Related to:
- #3294
- https://caddy.community/t/v2-logging-format/7642/4?u=matt
- https://caddy.community/t/caddyfile-questions/7651/3?u=matt
* caddyhttp: General improvements to access log controls (fixes #3310)
* caddyhttp: Move log config nil check higher
* Rename LoggerName -> DefaultLoggerName
|
|
Sigh, apparently Linux is incapable of distinguishing host interfaces
in socket addresses, even though it works fine on Mac. I suppose we just
have to assume that any listeners with the same port are the same
address, completely ignoring the host interface on Linux... oh well.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Wrapping listeners is useful for composing custom behavior related
to accepting, closing, reading/writing connections (etc) below the
application layer; for example, the PROXY protocol.
|
|
|
|
* caddytls: Add CipherSuiteName and ProtocolName functions
The cipher_suites.go file is derived from a commit to the Go master
branch that's slated for Go 1.14. Once Go 1.14 is released, this file
can be removed.
* caddyhttp: Use commonLogEmptyValue in common_log replacer
* caddyhttp: Add TLS placeholders
* caddytls: update unsupportedProtocols
Don't export unsupportedProtocols and update its godoc to mention that
it's used for logging only.
* caddyhttp: simplify getRegTLSReplacement signature
getRegTLSReplacement should receive a string instead of a pointer.
* caddyhttp: Remove http.request.tls.client.cert replacer
The previous behavior of printing the raw certificate bytes was ported
from Caddy 1, but the usefulness of that approach is suspect. Remove
the client cert replacer from v2 until a use case is presented.
* caddyhttp: Use tls.CipherSuiteName from Go 1.14
Remove ported version of CipherSuiteName in the process.
|
|
|
|
This splits automatic HTTPS into two phases. The first provisions the
route matchers and uses them to build the domain set and configure
auto HTTP->HTTPS redirects. This happens before the rest of the
provisioning does.
The second phase takes place at the beginning of the app start. It
attaches pointers to the tls app to each server, and begins certificate
management for the domains that were found in the first phase.
|
|
Previously, all matchers in a route would be evaluated before any
handlers were executed, and a composite route of the matching routes
would be created. This made rewrites especially tricky, since the only
way to defer later matchers' evaluation was to wrap them in a subroute,
or to invoke a "rehandle" which often caused bugs.
Instead, this new sequential design evaluates each route's matchers then
its handlers in lock-step; matcher-handlers-matcher-handlers...
If the first matching route consists of a rewrite, then the second route
will be evaluated against the rewritten request, rather than the original
one, and so on.
This should do away with any need for rehandling.
I've also taken this opportunity to avoid adding new values to the
request context in the handler chain, as this creates a copy of the
Request struct, which may possibly lead to bugs like it has in the past
(see PR #1542, PR #1481, and maybe issue #2463). We now add all the
expected context values in the top-level handler at the server, then
any new values can be added to the variable table via the VarsCtxKey
context key, or just the GetVar/SetVar functions. In particular, we are
using this facility to convey dial information in the reverse proxy.
Had to be careful in one place as the middleware compilation logic has
changed, and moved a bit. We no longer compile a middleware chain per-
request; instead, we can compile it at provision-time, and defer only the
evaluation of matchers to request-time, which should slightly improve
performance. Doing this, however, we take advantage of multiple function
closures, and we also changed the use of HandlerFunc (function pointer)
to Handler (interface)... this led to a situation where, if we aren't
careful, allows one request routed a certain way to permanently change
the "next" handler for all/most other requests! We avoid this by making
a copy of the interface value (which is a lightweight pointer copy) and
using exclusively that within our wrapped handlers. This way, the
original stack frame is preserved in a "read-only" fashion. The comments
in the code describe this phenomenon.
This may very well be a breaking change for some configurations, however
I do not expect it to impact many people. I will make it clear in the
release notes that this change has occurred.
|
|
|
|
The interface was only making things difficult; a concrete pointer is
probably best.
|