Cutlery/caddy
1
0
Fork 0
mirror of https://github.com/caddyserver/caddy.git synced 2025-06-23 15:31:40 -04:00
Code Issues Actions Packages Projects Releases Wiki Activity

Destroyed Caddyfile Directives (markdown)

Matt Holt 2015-04-15 16:14:44 -06:00
parent 9bc2bd55ef
commit 55819896e9
1 changed files with 0 additions and 143 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

143
Caddyfile-Directives.md

@ -1,143 +0,0 @@
This page describes the Caddyfile directives and how to use them. Each directive has a corresponding middleware which alters the behavior of the server.
This list is presented alphabetically. The order in which directives appear in the Caddyfile does not matter.
## List of directives
#### cpu
Caps the CPU use to the number of cores (or percentage) specified. By default, all cores may be used to serve requests. This directive is actually process-wide, meaning that it applies to ALL servers started with the same `caddy` process. If specified multiple times in a Caddyfile, the highest value is used. Can be a number of cores (at least 1) or a percent (between 1% and 100%).
```
cpu 50%
```
#### ext
Internally adds extensions to the requests. Extensions will be tried in the order listed. This allows you to easily serve cleaner URLs.
```
ext .html .html .txt
```
#### gzip
Enables gzip compression if the client supports it.
```
gzip
```
#### fastcgi
Forwards requests to a FastCGI server. This allows you to serve PHP websites with php-fpm, though it is not limited to that. The first argument should be the base path to match, and the second argument is the address that the FastCGI server (like php-fpm) is listening on. Multiple fastcgi forwarding rules can be created (you can use this directive multiple times).
```
fastcgi /app 127.0.0.1:9000
```
#### header
Adds header(s) of the specified name and value to the responses of requests matching the request path. You can specify a single header and value on a line or group them under the same path with curly braces.
```
header /one X-Some-Header 1
header /multiple {
Access-Control-Allow-Origin *
Access-Control-Allow-Methods "POST, GET, OPTIONS"
}
```
#### import
Import acts like "include" in other languages/syntaxes. It replaces that line with the contents of another file. Useful for reusing common settings.
```
import shared.conf
```
#### log
Activates logging. Right now, only requests can be logged. You may optionally specify an output file and format.
```
log requests /var/log/access.log "Got a request: {method} {path}"
```
To specify a format but use the default filename, use `_` as the filename (like Go's blank identifier). The filename can also be "stdout" or "stderr" instead of an actual file.
The following variables are available when specifying the format:
- {method}
- {scheme}
- {host}
- {path}
- {query}
- {fragment}
- {proto}
- {remote}
- {port}
- {uri}
- {when}
- {status}
- {size}
#### proxy
A simple reverse proxy. (This capability is slated for expansion soon.) Right now, it simply forwards a request matching the first argument to the second argument.
```
proxy /from http://example.com/to
```
#### redirect
HTTP redirect with the given status code.
```
redirect /from /to 302
```
#### rewrite
Internally rewrites a request from one path to another.
```
rewrite /from /to
```
#### root
Specifies the root directory from which to serve files.
```
root /usr/www
```
#### tls
Enables TLS (for HTTPS connections) using the specified certificate and key files.
```
tls cert.pem key.pem
```
#### websocket
Configures a WebSocket endpoint which runs the specified command. Each connection starts a separate process, so they are isolated from each other. The `stdin` and `stdout` of the running process are set to the web socket connection, so the client can communicate with the program directly. Environment variables are set for the running process according to the CGI 1.1 spec. You may specify multiple websocket endpoints.
```
websocket /echo cat
```