mirror of
https://github.com/caddyserver/website.git
synced 2025-04-20 12:15:08 -04:00
docs: caddyfile: Clarify that not all directives accept matcher tokens
This commit is contained in:
parent
668d145ecc
commit
72882011fc
2 changed files with 7 additions and 5 deletions
|
@ -163,7 +163,7 @@ By default, a directive that injects an HTTP handler applies to all requests (un
|
||||||
|
|
||||||
**Request matchers** can be used to classify requests by a given criteria. This concept originates in the [underlying JSON](/docs/json/apps/http/servers/routes/match/) structure, and it's important to know how to use them in the Caddyfile. With matchers, you can specify exactly which requests a directive applies to.
|
**Request matchers** can be used to classify requests by a given criteria. This concept originates in the [underlying JSON](/docs/json/apps/http/servers/routes/match/) structure, and it's important to know how to use them in the Caddyfile. With matchers, you can specify exactly which requests a directive applies to.
|
||||||
|
|
||||||
To limit a directive's scope, use a **matcher token** immediately after the directive. It can be one of these forms:
|
To limit a directive's scope, use a **matcher token** immediately after the directive, [if the directive supports matchers](/docs/caddyfile/directives#matchers). The matcher token can be one of these forms:
|
||||||
|
|
||||||
1. **`*`** to match all requests (wildcard; default).
|
1. **`*`** to match all requests (wildcard; default).
|
||||||
2. **`/path`** start with a forward slash to match a request path.
|
2. **`/path`** start with a forward slash to match a request path.
|
||||||
|
@ -212,8 +212,8 @@ For example:
|
||||||
|
|
||||||
```
|
```
|
||||||
@websockets {
|
@websockets {
|
||||||
header_regexp Connection Upgrade
|
header Connection *Upgrade*
|
||||||
header Upgrade websocket
|
header Upgrade websocket
|
||||||
}
|
}
|
||||||
reverse_proxy @websockets localhost:6001
|
reverse_proxy @websockets localhost:6001
|
||||||
```
|
```
|
||||||
|
|
|
@ -51,13 +51,15 @@ Subdirectives are always optional unless documented otherwise, even though they
|
||||||
|
|
||||||
### Matchers
|
### Matchers
|
||||||
|
|
||||||
Most directives accept [matcher tokens](/docs/caddyfile/concepts#matchers), and they are usually optional. You will often see this in a directive's syntax description:
|
Most---but not all---directives accept [matcher tokens](/docs/caddyfile/concepts#matchers), which let you filter requests. Matcher tokens are usually optional. If you see this in a directive's syntax:
|
||||||
|
|
||||||
```
|
```
|
||||||
[<matcher>]
|
[<matcher>]
|
||||||
```
|
```
|
||||||
|
|
||||||
When you see this in the syntax of a directive, it means a matcher token. Because this is the same with most directives, it will not be described on every page; this reduces duplication. Instead, refer to the centralized [matcher documentation](/docs/caddyfile/concepts#matchers).
|
then the directive accepts a matcher token, letting you filter which requests the directive applies to.
|
||||||
|
|
||||||
|
Because matcher tokens all work the same, the various possibilities for the matcher token will not be described on every page, to reduce duplication. Instead, refer to the centralized [matcher documentation](/docs/caddyfile/concepts#matchers).
|
||||||
|
|
||||||
|
|
||||||
## Directive order
|
## Directive order
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue