Age | Commit message (Collapse) | Author |
|
|
|
* v2: housekeeping: update tools
* v2: housekeeping: adhere to US locale in spelling
* v2: housekeeping: simplify code
|
|
|
|
|
|
|
|
The interface was only making things difficult; a concrete pointer is
probably best.
|
|
It seems silly to have to add a single, empty TLS connection policy to
a server to enable TLS when it's only listening on the HTTPS port. We
now do this for the user as part of automatic HTTPS (thus, it can be
disabled / overridden).
See https://caddy.community/t/v2-catch-all-server-with-automatic-tls/6692/2?u=matt
|
|
|
|
|
|
|
|
These will be used in the new automated documentation system
|
|
|
|
|
|
(Try saying "patch path match" ten times fast)
|
|
* Implement UDP writer
* Implement Net Writer
* Utilize Caddy's address parsing functions
* A couple little fixes (see #2884)
|
|
|
|
Also some minor cleanup/improvements discovered along the way
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
* fixes query matcher parsing
* return correct argument error when parsing query matcher
|
|
|
|
|
|
|
|
Also add godoc for Caddyfile syntax for file_server
|
|
|
|
Also little comment cleanups
|
|
If enabled, will call the next handler in the chain instead of returning
a 404.
|
|
This is a bad idea, but some backends apparently require it. See
discussion in #176.
|
|
|
|
This makes it easier to use multiple instances on the same machine
|
|
|
|
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
|
|
|
|
|
|
* Add support for placeholders in Config
Fixes #2870
* Replace placeholders only in logging config.
Placeholders in log level and filename incase of file output are replaced.
* Add Provision to filewriter module for replacing placeholders
|
|
D'oh. Got mixed up in a refactoring.
|
|
|
|
|
|
|
|
|
|
Also allow caddy.Duration to be given integer values which are treated
like regular time.Duration values (nanoseconds).
Fixes #2856
|
|
|
|
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.
|