mirror of
https://github.com/caddyserver/website.git
synced 2025-05-06 11:47:12 -04:00
docs: Review feedback
This commit is contained in:
parent
0a07434a42
commit
49f13c098e
4 changed files with 11 additions and 11 deletions
|
@ -25,11 +25,11 @@ If you prefer crafting HTTP handler logic in a more inheritence-based way like n
|
|||
|
||||
## Similar directives
|
||||
|
||||
There are other directives that can wrap other HTTP handler directives, but but imply a different intent or behave subtly differently:
|
||||
There are other directives that can wrap HTTP handler directives, but each has its use depending on the behavior you want to convey:
|
||||
|
||||
- [`handle_path`](handle_path) does the same as `handle`, but also has built-in path prefix stripping logic built-in before handling the directives within.
|
||||
- [`handle_errors`](handle_errors), similarly to `handle`, wraps other directives, but is instead invoked when Caddy encounters an error during request handling.
|
||||
- [`route`](route) similarly to `handle`, wraps other directives, but instead of providing mutual exclusivity, allows overriding the default [directive order](/docs/caddyfile/directives#directive-order).
|
||||
- [`handle_path`](handle_path) does the same as `handle`, but it strips a prefix from the request before running its handlers.
|
||||
- [`handle_errors`](handle_errors) is like `handle`, but is only invoked when Caddy encounters an error during request handling.
|
||||
- [`route`](route) wraps other directives like `handle` does, but with two distinctions: 1) route blocks are not mutually exclusive to each other, and 2) directives within a route are not [re-ordered]([directive order](/docs/caddyfile/directives#directive-order), giving you more control if needed.
|
||||
|
||||
## Examples
|
||||
|
||||
|
|
|
@ -91,7 +91,7 @@ Note: Schemes cannot be mixed, since they modify the common transport configurat
|
|||
|
||||
Additionally, upstream addresses cannot contain paths or query strings, as that would imply simultaneous rewriting the request while proxying, which behavior is not defined or supported. You may use the [`rewrite`](/docs/caddyfile/directives/rewrite) directive should you need this.
|
||||
|
||||
If the address is not a URL (i.e. does not have a scheme), then placeholders can be used, but this makes the upstream dynamic.
|
||||
If the address is not a URL (i.e. does not have a scheme), then placeholders can be used, but this makes the upstream dynamic, meaning that the potentially many different backends act as one upstream in terms of health checks and load balancing.
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -65,11 +65,11 @@ And now `file_server` will be chained in before `redir` because the order is tak
|
|||
|
||||
## Similar directives
|
||||
|
||||
There are other directives that can wrap other HTTP handler directives, but but imply a different intent or behave subtly differently:
|
||||
There are other directives that can wrap HTTP handler directives, but each has its use depending on the behavior you want to convey:
|
||||
|
||||
- [`handle`](route) similarly to `route`, wraps other directives, but instead overriding the default directive order, provides mutual exclusivity with other `handle` blocks.
|
||||
- [`handle_path`](handle_path) does the same as `handle`, but also has built-in path prefix stripping logic built-in before handling the directives within.
|
||||
- [`handle_errors`](handle_errors), similarly to `route`, wraps other directives, but is instead invoked when Caddy encounters an error during request handling.
|
||||
- [`handle`](route) wraps other directives like `route` does, but with two distinctions: 1) handle blocks are mutually exclusive to each other, and 2) directives with a handle are [re-ordered]([directive order](/docs/caddyfile/directives#directive-order) normally.
|
||||
- [`handle_path`](handle_path) does the same as `handle`, but it strips a prefix from the request before running its handlers.
|
||||
- [`handle_errors`](handle_errors) is like `handle`, but is only invoked when Caddy encounters an error during request handling.
|
||||
|
||||
## Examples
|
||||
|
||||
|
|
|
@ -235,7 +235,7 @@ Because this command uses the API, the admin endpoint must not be disabled.
|
|||
|
||||
`--address` needs to be used if the admin endpoint is not listening on the default address and if it is different from the address in the provided config file. Note that only TCP addresses are supported at this time.
|
||||
|
||||
`--force` will cause a reload to happen even if the specified config is the same as the one the running Caddy instance is already using. Can be useful to force Caddy to reload TLS certificate files specified to load in the config, if they've become stale.
|
||||
`--force` will cause a reload to happen even if the specified config is the same as what Caddy is already running. Can be useful to force Caddy to reprovision its modules, which can have side-effects, for example: reloading manually-loaded TLS certificates.
|
||||
|
||||
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue