This commit goes a long way toward making automated documentation of
Caddy config and Caddy modules possible. It's a broad, sweeping change,
but mostly internal. It allows us to automatically generate docs for all
Caddy modules (including future third-party ones) and make them viewable
on a web page; it also doubles as godoc comments.
As such, this commit makes significant progress in migrating the docs
from our temporary wiki page toward our new website which is still under
construction.
With this change, all host modules will use ctx.LoadModule() and pass in
both the struct pointer and the field name as a string. This allows the
reflect package to read the struct tag from that field so that it can
get the necessary information like the module namespace and the inline
key.
This has the nice side-effect of unifying the code and documentation. It
also simplifies module loading, and handles several variations on field
types for raw module fields (i.e. variations on json.RawMessage, such as
arrays and maps).
I also renamed ModuleInfo.Name -> ModuleInfo.ID, to make it clear that
the ID is the "full name" which includes both the module namespace and
the name. This clarity is helpful when describing module hierarchy.
As of this change, Caddy modules are no longer an experimental design.
I think the architecture is good enough to go forward.
Adds tests for both the path matcher and host matcher for case
insensitivity.
If case sensitivity is required for the path, a regexp matcher can
be used instead.
This is the v2 equivalent fix of PR #2882.
* fix OOM issue caught by fuzzing
* use ParsedAddress as the struct name for the result of ParseNetworkAddress
* simplify code using the ParsedAddress type
* minor cleanups
Errors in the 4xx range are client errors, and they don't need to be
entered into the server's error logs. 4xx errors are still recorded in
the access logs at the error level.
This makes it easier to make "standard" caddy builds, since you'll only
need to add a single import to get all of Caddy's standard modules.
There is a package for all of Caddy's standard modules (modules/standard)
and a package for the HTTP app's standard modules only
(modules/caddyhttp/standard).
We still need to decide which of these, if not all of them, should be
kept in the standard build. Those which aren't should be moved out of
this repo. See #2780.
* logging: Initial implementation
* logging: More encoder formats, better defaults
* logging: Fix repetition bug with FilterEncoder; add more presets
* logging: DiscardWriter; delete or no-op logs that discard their output
* logging: Add http.handlers.log module; enhance Replacer methods
The Replacer interface has new methods to customize how to handle empty
or unrecognized placeholders. Closes#2815.
* logging: Overhaul HTTP logging, fix bugs, improve filtering, etc.
* logging: General cleanup, begin transitioning to using new loggers
* Fixes after merge conflict
* file_server: Make tests work on Windows
* caddyfile: Fix escaping when character is not escapable
We only escape certain characters depending on inside or outside of
quotes (mainly newlines and quotes). We don't want everyone to have to
escape Windows file paths like C:\\Windows\\... but we can't drop the
\ either if it's just C:\Windows\...
* v2: split golangci-lint configuration into its own file to allow code editors to take advantage of it
* v2: simplify code
* v2: set the correct lint output formatting
* v2: invert the logic of linter's configuration of output formatting to allow the editor convenience over CI-specific customization. Customize the output format in CI by passing the flag.
* v2: remove irrelevant golangci-lint config
This PR enables the use of placeholders in an upstream's Dial address.
A Dial address must represent precisely one socket after replacements.
See also #998 and #1639.
This implements HTTP basicauth into Caddy 2. The basic auth module will
not work with passwords that are not securely hashed, so a subcommand
hash-password was added to make it convenient to produce those hashes.
Also included is Caddyfile support.
Closes#2747.
This migrates a feature that was previously reserved for enterprise
users, according to #2786.
The Starlark integration needs to be updated since this was made before
some significant changes in the v2 code base. When functional, it makes
it possible to have very dynamic HTTP handlers. This will be a long-term
ongoing project.
Credit to Danny Navarro
This migrates a feature that was previously reserved for enterprise
users, according to https://github.com/caddyserver/caddy/issues/2786.
The local circuit breaker is a simple metrics counter that can cause
the reverse proxy to consider a backend unhealthy before it actually
goes offline, by measuring recent latencies over a sliding window.
Credit to Danny Navarro
This migrates a feature that was previously reserved for enterprise
users, according to https://github.com/caddyserver/caddy/issues/2786.
The cache HTTP handler will be a high-performing, distributed cache
layer for HTTP requests. Right now, the implementation is a very basic
proof-of-concept, and further development is required.
Making them pointers makes for cleaner JSON when adapting configs, if
the struct is empty now it will be omitted entirely.
The x/time/rate package was updated to support changing the burst, so
we've incorporated that here and removed a TODO.
Before this change, only response headers could be manipulated with the
Caddyfile's 'header' directive.
Also handle the request Host header specially, since the Go standard
library treats it separately from the other header fields...
* Begin WIP integration of HTTP/3 support
* http3: Set actual Handler, make fakeClosePacketConn type for UDP sockets
Also use latest quic-go for ALPN fix
* Manually keep track of and close HTTP/3 listeners
* Update quic-go after working through some http3 bugs
* Fix go mod
* Make http3 optional for now
See: https://stackoverflow.com/a/12518877/1048862
For example, trying to check the existence of "/www/index.php/index.php"
fails but not with an os.IsNotExist()-type error. So we have to assume
that a file that cannot be successfully stat'ed at all does not exist.
- Rename http.var.* -> http.vars.* to be more consistent
- Prefixing a path matcher with * now invokes simple suffix matching
- Handlers and matchers that need a root path default to {http.vars.root}
- Clean replacer output on the file matcher's file selection suffix
* Add support for client TLS authentication
Signed-off-by: Alexandre Stein <alexandre_stein@interlab-net.com>
* make and use client authentication struct
* force StrictSNIHost if TLSConnPolicies is not empty
* Implement leafs verification
* Fixes issue when using multiple verification
* applies the comments from maintainers
* Apply comment
* Refactor/cleanup initial TLS client auth implementation
Use piles from which to draw config values.
Module values can return their name, so now we can do two-way mapping
from value to name and name to value; whereas before we could only map
name to value. This was problematic with the Caddyfile adapter since
it receives values and needs to know the name to put in the config.
Along with several other changes, such as renaming caddyhttp.ServerRoute
to caddyhttp.Route, exporting some types that were not exported before,
and tweaking the caddytls TLS values to be more consistent.
Notably, we also now disable automatic cert management for names which
already have a cert (manually) loaded into the cache. These names no
longer need to be specified in the "skip_certificates" field of the
automatic HTTPS config, because they will be skipped automatically.
* optimized functions for inlining
* added note regarding ResponseWriterWrapper
* optimzed browseWrite* methods for FileServer
* created benchmarks for comparison
* creating browseListing instance in each function
* created benchmarks for openResponseWriter
* removed benchmarks of old implementations
* implemented sync.Pool for byte buffers
* using global sync.Pool for writing JSON/HTML
Differentiating middleware and responders has one benefit, namely that
it's clear which module provides the response, but even then it's not
a great advantage. Linear handler config makes a little more sense,
giving greater flexibility and simplifying the core a bit, even though
it's slightly awkward that handlers which are responders may not use
the 'next' handler that is passed in at all.