mirror of
https://github.com/caddyserver/website.git
synced 2025-04-22 13:06:16 -04:00
Fix typos
This commit is contained in:
parent
8d5d93b379
commit
5daefb22d5
13 changed files with 15 additions and 15 deletions
|
@ -33,7 +33,7 @@ The **[core library](https://pkg.go.dev/github.com/caddyserver/caddy/v2?tab=doc)
|
||||||
|
|
||||||
<aside class="tip">
|
<aside class="tip">
|
||||||
|
|
||||||
Sometimes the terms *module*, *plugin*, and *extension* get used interchangably, and usually that's OK. Technically, all modules are plugins, but not all plugins are modules. Modules are specifically a kind of plugin that extends Caddy's [config structure](/docs/json/).
|
Sometimes the terms *module*, *plugin*, and *extension* get used interchangeably, and usually that's OK. Technically, all modules are plugins, but not all plugins are modules. Modules are specifically a kind of plugin that extends Caddy's [config structure](/docs/json/).
|
||||||
|
|
||||||
</aside>
|
</aside>
|
||||||
|
|
||||||
|
|
|
@ -206,7 +206,7 @@ You can then define as many different sites as you want, as long as each address
|
||||||
|
|
||||||
We may want to apply some directives only to certain requests. For example, let's suppose we want to have both a file server and a reverse proxy, but we obviously can't do both on every request! Either the file server will write a response with a static file, or the reverse proxy will pass the request to a backend and write back its response.
|
We may want to apply some directives only to certain requests. For example, let's suppose we want to have both a file server and a reverse proxy, but we obviously can't do both on every request! Either the file server will write a response with a static file, or the reverse proxy will pass the request to a backend and write back its response.
|
||||||
|
|
||||||
This config will not work like we want (`reverse_proxy` will take precendence due to the [directive order](/docs/caddyfile/directives#directive-order)):
|
This config will not work like we want (`reverse_proxy` will take precedence due to the [directive order](/docs/caddyfile/directives#directive-order)):
|
||||||
|
|
||||||
```caddy
|
```caddy
|
||||||
localhost
|
localhost
|
||||||
|
|
|
@ -196,6 +196,6 @@ For ease of use, the Caddyfile adapter sorts directives according to the followi
|
||||||
|
|
||||||
- A directive with no matcher (i.e. matching all requests) is sorted last.
|
- A directive with no matcher (i.e. matching all requests) is sorted last.
|
||||||
|
|
||||||
- The [`vars`](/docs/caddyfile/directives/vars) directive has its ordering by matcher reversed, because it involves setting values which can overwrite eachother, so the most specific matcher should be evaluated last.
|
- The [`vars`](/docs/caddyfile/directives/vars) directive has its ordering by matcher reversed, because it involves setting values which can overwrite each other, so the most specific matcher should be evaluated last.
|
||||||
|
|
||||||
- The contents of the [`route`](/docs/caddyfile/directives/route) directive ignores all the above rules, and preserves the order the directives appear within.
|
- The contents of the [`route`](/docs/caddyfile/directives/route) directive ignores all the above rules, and preserves the order the directives appear within.
|
||||||
|
|
|
@ -57,7 +57,7 @@ file_server [<matcher>] [browse] {
|
||||||
|
|
||||||
- **browse** <span id="browse"/> enables file listings for requests to directories that do not have an index file.
|
- **browse** <span id="browse"/> enables file listings for requests to directories that do not have an index file.
|
||||||
|
|
||||||
- **<template_file>** <span id="template_file"/> is an optional custom template file to use for directory listings. Defaults to the template that can be extracted using the command `caddy file-server export-template`, which will print the defaut template to stdout. The embedded template can also be found [here in the source code ](https://github.com/caddyserver/caddy/blob/master/modules/caddyhttp/fileserver/browse.html). Browse templates can use actions from [the standard templates module](/docs/modules/http.handlers.templates#docs) as well.
|
- **<template_file>** <span id="template_file"/> is an optional custom template file to use for directory listings. Defaults to the template that can be extracted using the command `caddy file-server export-template`, which will print the default template to stdout. The embedded template can also be found [here in the source code ](https://github.com/caddyserver/caddy/blob/master/modules/caddyhttp/fileserver/browse.html). Browse templates can use actions from [the standard templates module](/docs/modules/http.handlers.templates#docs) as well.
|
||||||
|
|
||||||
- **reveal_symlinks** <span id="reveal_symlinks"/> enables revealing the targets of symbolic links in directory listings. By default, the symlink targets are hidden, and only the link file itself is shown.
|
- **reveal_symlinks** <span id="reveal_symlinks"/> enables revealing the targets of symbolic links in directory listings. By default, the symlink targets are hidden, and only the link file itself is shown.
|
||||||
|
|
||||||
|
|
|
@ -35,7 +35,7 @@ An opinionated directive which proxies a clone of the request to an authenticati
|
||||||
- [Authelia](#authelia)
|
- [Authelia](#authelia)
|
||||||
- [Tailscale](#tailscale)
|
- [Tailscale](#tailscale)
|
||||||
|
|
||||||
Caddy's [`reverse_proxy`](/docs/caddyfile/directives/reverse_proxy) is capable of performing "pre-check requests" to an external service, but this directive is tailored specifically for the authentication usecase. This directive is actually just a convenient way to use a longer, more common configuration (below).
|
Caddy's [`reverse_proxy`](/docs/caddyfile/directives/reverse_proxy) is capable of performing "pre-check requests" to an external service, but this directive is tailored specifically for the authentication use case. This directive is actually just a convenient way to use a longer, more common configuration (below).
|
||||||
|
|
||||||
This directive makes a `GET` request to the configured upstream with the `uri` rewritten:
|
This directive makes a `GET` request to the configured upstream with the `uri` rewritten:
|
||||||
- If the upstream responds with a `2xx` status code, then access is granted and the header fields in `copy_headers` are copied to the original request, and handling continues.
|
- If the upstream responds with a `2xx` status code, then access is granted and the header fields in `copy_headers` are copied to the original request, and handling continues.
|
||||||
|
|
|
@ -40,7 +40,7 @@ push [<matcher>] [<resource>] {
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
- **<resource>** is the target URI path to push. If used within the block, may optionally be preceeded by the method (GET or POST; GET is default).
|
- **<resource>** is the target URI path to push. If used within the block, may optionally be preceded by the method (GET or POST; GET is default).
|
||||||
- **<headers>** manipulates the headers of the push request using the same syntax as the [`header` directive](/docs/caddyfile/directives/header). Some headers are carried over by default and do not need to be explicitly configured (see above).
|
- **<headers>** manipulates the headers of the push request using the same syntax as the [`header` directive](/docs/caddyfile/directives/header). Some headers are carried over by default and do not need to be explicitly configured (see above).
|
||||||
|
|
||||||
|
|
||||||
|
|
|
@ -310,11 +310,11 @@ This is enabled by default, with the `random` policy. Retries are disabled by de
|
||||||
|
|
||||||
- **lb_try_duration** <span id="lb_try_duration"/> is a [duration value](/docs/conventions#durations) that defines how long to try selecting available backends for each request if the next available host is down. By default, retries are disabled (zero duration).
|
- **lb_try_duration** <span id="lb_try_duration"/> is a [duration value](/docs/conventions#durations) that defines how long to try selecting available backends for each request if the next available host is down. By default, retries are disabled (zero duration).
|
||||||
|
|
||||||
Clients will wait for up to this long while the load balancer tries to find an available upstream host. A reasonable starting point might be `5s` since the HTTP transport's default dial timeout is `3s`, so that should allow for at least one retry if the first selected upstream cannot be reached; but feel free to experiment to find the right balance for your usecase.
|
Clients will wait for up to this long while the load balancer tries to find an available upstream host. A reasonable starting point might be `5s` since the HTTP transport's default dial timeout is `3s`, so that should allow for at least one retry if the first selected upstream cannot be reached; but feel free to experiment to find the right balance for your use case.
|
||||||
|
|
||||||
- **lb_try_interval** <span id="lb_try_interval"/> is a [duration value](/docs/conventions#durations) that defines how long to wait between selecting the next host from the pool. Default is `250ms`. Only relevant when a request to an upstream host fails. Be aware that setting this to `0` with a non-zero `lb_try_duration` can cause the CPU to spin if all backends are down and latency is very low.
|
- **lb_try_interval** <span id="lb_try_interval"/> is a [duration value](/docs/conventions#durations) that defines how long to wait between selecting the next host from the pool. Default is `250ms`. Only relevant when a request to an upstream host fails. Be aware that setting this to `0` with a non-zero `lb_try_duration` can cause the CPU to spin if all backends are down and latency is very low.
|
||||||
|
|
||||||
- **lb_retry_match** <span id="lb_retry_match"/> restricts with which requests retries are allowed. A request must match this condition in order to be retried if the connection to the upstream succeded but the subsequent round-trip failed. If the connection to the upstream failed, a retry is always allowed. By default, only `GET` requests are retried.
|
- **lb_retry_match** <span id="lb_retry_match"/> restricts with which requests retries are allowed. A request must match this condition in order to be retried if the connection to the upstream succeeded but the subsequent round-trip failed. If the connection to the upstream failed, a retry is always allowed. By default, only `GET` requests are retried.
|
||||||
|
|
||||||
The syntax for this option is the same as for [named request matchers](/docs/caddyfile/matchers#named-matchers), but without the `@name`. If you only need a single matcher, you may configure it on the same line. For multiple matchers, a block is necessary.
|
The syntax for this option is the same as for [named request matchers](/docs/caddyfile/matchers#named-matchers), but without the `@name`. If you only need a single matcher, you may configure it on the same line. For multiple matchers, a block is necessary.
|
||||||
|
|
||||||
|
@ -350,7 +350,7 @@ Active health checks perform health checking in the background on a timer. To en
|
||||||
|
|
||||||
Passive health checks happen inline with actual proxied requests. To enable this, `fail_duration` is required.
|
Passive health checks happen inline with actual proxied requests. To enable this, `fail_duration` is required.
|
||||||
|
|
||||||
- **fail_duration** <span id="fail_duration"/> is a [duration value](/docs/conventions#durations) that defines how long to remember a failed request. A duration > `0` enables passive health checking; the default is `0` (off). A reasonable starting point might be `30s` to balance error rates with responsiveness when bringing an unhealthy upstream back online; but feel free to experiment to find the right balance for your usecase.
|
- **fail_duration** <span id="fail_duration"/> is a [duration value](/docs/conventions#durations) that defines how long to remember a failed request. A duration > `0` enables passive health checking; the default is `0` (off). A reasonable starting point might be `30s` to balance error rates with responsiveness when bringing an unhealthy upstream back online; but feel free to experiment to find the right balance for your use case.
|
||||||
|
|
||||||
- **max_fails** <span id="max_fails"/> is the maximum number of failed requests within `fail_duration` that are needed before considering a backend to be down; must be >= `1`; default is `1`.
|
- **max_fails** <span id="max_fails"/> is the maximum number of failed requests within `fail_duration` that are needed before considering a backend to be down; must be >= `1`; default is `1`.
|
||||||
|
|
||||||
|
|
|
@ -401,7 +401,7 @@ Obtains certificates from an internal certificate authority.
|
||||||
|
|
||||||
Caddy will attempt to install the root CA certificate to the system trust store, but this may fail when Caddy is running as an unprivileged user, or when running in a Docker container. In that case, the root CA certificate will need to be manually installed, either by using the [`caddy trust`](/docs/command-line#caddy-trust) command, or by [copying out of the container](/docs/running#usage).
|
Caddy will attempt to install the root CA certificate to the system trust store, but this may fail when Caddy is running as an unprivileged user, or when running in a Docker container. In that case, the root CA certificate will need to be manually installed, either by using the [`caddy trust`](/docs/command-line#caddy-trust) command, or by [copying out of the container](/docs/running#usage).
|
||||||
|
|
||||||
- **lifetime** <span id="lifetime"/> is a [duration value](/docs/conventions#durations) that sets the validity period for interally issued leaf certificates. Default: `12h`. It is NOT recommended to change this, unless absolutely necessary. It must be shorter than the intermediate's lifetime.
|
- **lifetime** <span id="lifetime"/> is a [duration value](/docs/conventions#durations) that sets the validity period for internally issued leaf certificates. Default: `12h`. It is NOT recommended to change this, unless absolutely necessary. It must be shorter than the intermediate's lifetime.
|
||||||
|
|
||||||
- **sign_with_root** <span id="sign_with_root"/> forces the root to be the issuer instead of the intermediate. This is NOT recommended and should only be used when devices/clients do not properly validate certificate chains (very uncommon).
|
- **sign_with_root** <span id="sign_with_root"/> forces the root to be the issuer instead of the intermediate. This is NOT recommended and should only be used when devices/clients do not properly validate certificate chains (very uncommon).
|
||||||
|
|
||||||
|
|
|
@ -38,7 +38,7 @@ The `--flags` may have a single-letter shortcut like `-f`.
|
||||||
A simple but production-ready file server
|
A simple but production-ready file server
|
||||||
|
|
||||||
- **[caddy file-server export-template](#caddy-file-server-export-template)**
|
- **[caddy file-server export-template](#caddy-file-server-export-template)**
|
||||||
Auxilary command for the file server to export the default file browser template
|
Auxiliary command for the file server to export the default file browser template
|
||||||
|
|
||||||
- **[caddy fmt](#caddy-fmt)**
|
- **[caddy fmt](#caddy-fmt)**
|
||||||
Formats a Caddyfile
|
Formats a Caddyfile
|
||||||
|
|
|
@ -86,7 +86,7 @@ You should not process placeholders in [`UnmarshalCaddyfile()`](/docs/extending-
|
||||||
|
|
||||||
### Examples
|
### Examples
|
||||||
|
|
||||||
Here, we are using a newly constructed replacer to process placeholders. It has access to [global placeholders](/docs/conventions#placeholders) such as `{env.HOST}`, but _not_ HTTP placeholders such as `{http.request.uri}` because provisoning happens when the config is loaded, and not during a request.
|
Here, we are using a newly constructed replacer to process placeholders. It has access to [global placeholders](/docs/conventions#placeholders) such as `{env.HOST}`, but _not_ HTTP placeholders such as `{http.request.uri}` because provisioning happens when the config is loaded, and not during a request.
|
||||||
|
|
||||||
```go
|
```go
|
||||||
func (g *Gizmo) Provision(ctx caddy.Context) error {
|
func (g *Gizmo) Provision(ctx caddy.Context) error {
|
||||||
|
|
|
@ -33,7 +33,7 @@ The recommended way to run Caddy on Linux distributions with systemd is with our
|
||||||
|
|
||||||
### Unit Files
|
### Unit Files
|
||||||
|
|
||||||
We provide two different systemd unit files that you can choose between, depending on your usecase:
|
We provide two different systemd unit files that you can choose between, depending on your use case:
|
||||||
|
|
||||||
- [**`caddy.service`**](https://github.com/caddyserver/dist/blob/master/init/caddy.service) if you configure Caddy with a [Caddyfile](/docs/caddyfile). If you prefer to use a different config adapter or a JSON config file, you may [override](#overrides) the `ExecStart` and `ExecReload` commands.
|
- [**`caddy.service`**](https://github.com/caddyserver/dist/blob/master/init/caddy.service) if you configure Caddy with a [Caddyfile](/docs/caddyfile). If you prefer to use a different config adapter or a JSON config file, you may [override](#overrides) the `ExecStart` and `ExecReload` commands.
|
||||||
|
|
||||||
|
|
|
@ -4,7 +4,7 @@ title: Verifying Asset Signatures
|
||||||
|
|
||||||
# Signature Verification
|
# Signature Verification
|
||||||
|
|
||||||
Artifact signing allows you to validate the artifact you have is the same one created by the project's workflow and was not modified by an unauthorized party (e.g. man-in-the-middle). The validation provides common ground, assurance, and knowledge that all parties are refering to the same artifact, collection of bytes, whether it is an executable, SBOM, or text file.
|
Artifact signing allows you to validate the artifact you have is the same one created by the project's workflow and was not modified by an unauthorized party (e.g. man-in-the-middle). The validation provides common ground, assurance, and knowledge that all parties are referring to the same artifact, collection of bytes, whether it is an executable, SBOM, or text file.
|
||||||
|
|
||||||
As of Caddy v2.6.0, CI/CD release artifacts are signed using project [Sigstore](https://www.sigstore.dev/) technology, which issues certificates containing details about the subject to whom the certificate is issued. You can start by inspecting the certificate used to sign your artifact of choice. The certificates are base64-encoded, so you first have to base64-decode it to receive the PEM file. In this example, we'll work with the `caddy_2.6.0_checksums.txt` artifact and assume a Linux-like environment.
|
As of Caddy v2.6.0, CI/CD release artifacts are signed using project [Sigstore](https://www.sigstore.dev/) technology, which issues certificates containing details about the subject to whom the certificate is issued. You can start by inspecting the certificate used to sign your artifact of choice. The certificates are base64-encoded, so you first have to base64-decode it to receive the PEM file. In this example, we'll work with the `caddy_2.6.0_checksums.txt` artifact and assume a Linux-like environment.
|
||||||
|
|
||||||
|
|
|
@ -264,7 +264,7 @@ main nav li ul {
|
||||||
|
|
||||||
|
|
||||||
article {
|
article {
|
||||||
font-family: 'Albert Sans', system-ui; /* considered: Figtree, Asisstant, Red Hat Text, Be Vietnam Pro */
|
font-family: 'Albert Sans', system-ui; /* considered: Figtree, Assistant, Red Hat Text, Be Vietnam Pro */
|
||||||
font-size: 20px;
|
font-size: 20px;
|
||||||
word-wrap: break-word;
|
word-wrap: break-word;
|
||||||
|
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue