docs: Update a variety of docs for upcoming 2.1 betas

src/docs/markdown/caddyfile/concepts.md

@@ -141,6 +141,14 @@ directive "\"abc def\""
 
 Inside quoted tokens, all other characters are treated literally, including spaces, tabs, and newlines.
 
+You can also use a backtick (`\``) to quote tokens:
+
+```
+directive `"foo bar"`
+```
+
+Backtick strings are convenient when tokens contain quote literals.
+
 
 
 ## Addresses
@@ -219,11 +227,16 @@ You can use any [Caddy placeholders](/docs/conventions#placeholders) in the Cadd
 |-----------------|---------------------------------|
 | `{dir}`         | `{http.request.uri.path.dir}`   |
 | `{file}`        | `{http.request.uri.path.file}`  |
+| `{header.*}`    | `{http.request.header.*}`       |
 | `{host}`        | `{http.request.host}`           |
+| `{labels.*}`    | `{http.request.host.labels.*}`  |
 | `{hostport}`    | `{http.request.hostport}`       |
 | `{method}`      | `{http.request.method}`         |
 | `{path}`        | `{http.request.uri.path}`       |
+| `{path.*}`      | `{http.request.uri.path.*}`     |
 | `{query}`       | `{http.request.uri.query}`      |
+| `{query.*}`     | `{http.request.uri.query.*}`    |
+| `{re.*.*}`      | `{http.regexp.*.*}`             |
 | `{remote}`      | `{http.request.remote}`         |
 | `{remote_host}` | `{http.request.remote.host}`    |
 | `{remote_port}` | `{http.request.remote.port}`    |
@@ -237,6 +250,7 @@ You can use any [Caddy placeholders](/docs/conventions#placeholders) in the Cadd
 | `{tls_client_subject}`     | `{http.request.tls.client.subject}`     |
 
 
+
 ## Snippets
 
 You can define special blocks called snippets by giving them a name surrounded in parentheses:

src/docs/markdown/caddyfile/directives/reverse_proxy.md

@@ -62,7 +62,7 @@ Upstream addresses can take the form of a conventional [Caddy network address](/
 - `unix//var/php.sock`
 - `srv+http://internal:5099`
 
-Note: Schemes cannot be mixed, since they modify the common transport configuration (a TLS-enabled transport cannot carry both HTTPS and plaintext HTTP). Specifying ports 80 and 443 are the same as specifying the HTTP and HTTPS schemes, respectively. Any explicit transport configuration will not be overwritten, and omitting schemes or using other ports will not assume a particular transport. Additionally, schemes cannot contain paths or query strings, as that would imply simultaneous rewriting the request while proxying, which behavior is not defined or supported.
+Note: Schemes cannot be mixed, since they modify the common transport configuration (a TLS-enabled transport cannot carry both HTTPS and plaintext HTTP). Specifying ports 80 and 443 are the same as specifying the HTTP and HTTPS schemes, respectively. Any explicit transport configuration will not be overwritten, and omitting schemes or using other ports will not assume a particular transport. Additionally, schemes cannot contain paths or query strings, as that would imply simultaneous rewriting the request while proxying, which behavior is not defined or supported. 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.
 
 **Load balancing** is used whenever more than one upstream is defined.
 
@@ -128,6 +128,7 @@ transport http {
 	tls_insecure_skip_verify
 	tls_timeout <duration>
 	tls_trusted_ca_certs <pem_files...>
+    tls_server_name <sni>
 	keepalive [off|<duration>]
 	keepalive_idle_conns <max_count>
 }
@@ -141,6 +142,7 @@ transport http {
 - **tls_insecure_skip_verify** turns off security. _Do not use in production._
 - **tls_timeout** is a [duration value](/docs/conventions#durations) that specifies how long to wait for the TLS handshake to complete.
 - **tls_trusted_ca_certs** is a list of PEM files that specify CA public keys to trust when connecting to the backend.
+- **tls_server_name** sets the ServerName (SNI) to put in the ClientHello; only needed if the remote server it.
 - **keepalive** is either `off` or a [duration value](/docs/conventions#durations) that specifies how long to keep connections open.
 - **keepalive_idle_conns** defines the maximum number of connections to keep alive.
 

src/docs/markdown/caddyfile/matchers.md

@@ -62,10 +62,11 @@ reverse_proxy /api/* localhost:9000
 To match on anything other than a path, define a [named matcher](#named-matchers) and refer to it using `@name`:
 
 ```caddy-d
-@post {
+@postfoo {
 	method POST
+	path /foo/*
 }
-reverse_proxy @post localhost:9000
+reverse_proxy @postfoo localhost:9000
 ```
 
 
@@ -73,7 +74,7 @@ reverse_proxy @post localhost:9000
 
 ### Wildcard matchers
 
-The wildcard matcher `*` matches all requests, and is only needed if a matcher token is required. For example, if the first argument you want to give a directive also happens to be a path, it would look exactly like a path matcher! So you can use a wildcard matcher to disambiguate, for example:
+The wildcard (or "catch-all") matcher `*` matches all requests, and is only needed if a matcher token is required. For example, if the first argument you want to give a directive also happens to be a path, it would look exactly like a path matcher! So you can use a wildcard matcher to disambiguate, for example:
 
 ```caddy-d
 root * /home/www/mysite
@@ -97,6 +98,8 @@ Path matcher tokens must start with a forward slash `/`.
 
 ### Named matchers
 
+All matchers that are not comprised of a single path matcher or a wildcard matcher must be named matchers. This is a matcher that is defined outside of any particular directive, and can be reused.
+
 Defining a matcher with a unique name gives you more flexibility, allowing you to combine [any available matchers](#standard-matchers) into a set:
 
 ```caddy-d
@@ -105,6 +108,12 @@ Defining a matcher with a unique name gives you more flexibility, allowing you t
 }
 ```
 
+or, if there is only one matcher in the set:
+
+```
+@name ...
+```
+
 Then you can use the matcher like so: `@name`
 
 For example:
@@ -119,6 +128,15 @@ reverse_proxy @websockets localhost:6001
 
 This proxies only the requests that have a header field named "Connection" containing the word "Upgrade", and another field named "Upgrade" with a value of "websocket".
 
+If the matcher set consists of only one matcher, a one-liner syntax also works:
+
+```
+@post method POST
+reverse_proxy @post localhost:6001
+```
+
+(One-liner named matchers cannot open a block.)
+
 Like directives, named matcher definitions must go inside the site blocks that use them.
 
 A named matcher definition constitutes a _matcher set_. Matchers in a set are AND'ed together; i.e. all must match. For example, if you have both a `header` and `path` matcher in the set, both must match.
@@ -185,7 +203,13 @@ By files.
 	- `most_recent_modified` chooses the file that was most recently modified.
 - `split_path` will cause the path to be split at the first delimiter in the list that is found in each filepath to try. For each split value, the left-hand side of the split including the delimiter itself will be the filepath that is tried. For example, `/remote.php/dav/` using a delimiter of `.php` would try the file `/remote.php`. Each delimiter must appear at the end of a URI path component in order to be used as a split delimiter. This is a niche setting and is mostly used when serving PHP sites.
 
-An empty `file` matcher will see if the requested file (verbatim from the URI, relative to the [site root](/docs/caddyfile/directives/root)) exists.
+Because `try_files` with a policy of `first_exist` is so common, there is a one-line shortcut for that:
+
+```caddy-d
+file <files...>
+```
+
+An empty `file` matcher (one with no files listed after it) will see if the requested file&mdash;verbatim from the URI, relative to the [site root](/docs/caddyfile/directives/root)&mdash;exists.
 
 Since rewriting based on the existence of a file on disk is so common, there is also a [`try_files` directive](/docs/caddyfile/directives/try_files) which is a shortcut of the `file` matcher and a [`rewrite` handler](/docs/caddyfile/directives/rewrite).
 

src/docs/markdown/command-line.md

@@ -172,13 +172,13 @@ Formats or prettifies a Caddyfile, then exits. The result is printed to stdout u
 ### `caddy hash-password`
 
 <pre><code class="cmd bash">caddy hash-password
-	--plaintext &lt;password&gt;
+	[--plaintext &lt;password&gt;]
 	[--algorithm &lt;name&gt;]
 	[--salt &lt;string&gt;]</code></pre>
 
 Hashes a password and writes the output to stdout in base64 encoding, then exits.
 
-`--plaintext` is the plaintext form of the password.
+`--plaintext` is the plaintext form of the password. If omitted, interactive mode will be assumed and the user will be shown a prompt to enter the password manually.
 
 `--algorithm` may be bcrypt or scrypt. Default is bcrypt.
 

src/docs/markdown/conventions.md

@@ -140,7 +140,7 @@ It is crucial that this directory is persistent and writeable by Caddy.
 
 ## Durations
 
-Duration strings are commonly used throughout Caddy's configuration. They take on the same format as [Go's time.ParseDuration syntax](https://golang.org/pkg/time/#ParseDuration). Valid units are:
+Duration strings are commonly used throughout Caddy's configuration. They take on the same format as [Go's time.ParseDuration syntax](https://golang.org/pkg/time/#ParseDuration) except you can also use `d` for day (we assume 1 day = 24 hours for simplicity). Valid units are:
 
 - `ns` (nanosecond)
 - `us`/`µs` (microsecond)
@@ -148,6 +148,7 @@ Duration strings are commonly used throughout Caddy's configuration. They take o
 - `s` (second)
 - `m` (minute)
 - `h` (hour)
+- `d` (day)
 
 Examples:
 
@@ -155,5 +156,6 @@ Examples:
 - `5s`
 - `1.5h`
 - `2h45m`
+- `90d`
 
 In the [JSON config](/docs/json/), duration values can also be integers which represent nanoseconds.