docs: Add Caddyfile syntax highlighting

src/docs/markdown/caddyfile-tutorial.md

@@ -27,7 +27,7 @@ Create a new text file named `Caddyfile` (no extension).
 
 The first thing you should type is your site's [address](/docs/caddyfile/concepts#addresses):
 
-```
+```caddy
 localhost
 ```
 
@@ -37,7 +37,7 @@ localhost
 
 Then hit enter and type what you want it to do. For this tutorial, make your Caddyfile look like this:
 
-```
+```caddy
 localhost
 
 respond "Hello, world!"
@@ -63,7 +63,7 @@ Open [localhost](https://localhost) in your browser and see your web server work
 
 That's not particularly exciting, so let's change our static response to a [file server](/docs/caddyfile/directives/file_server) with directory listings enabled:
 
-```
+```caddy
 localhost
 
 file_server browse
@@ -99,7 +99,7 @@ Page loaded at: {{`{{`}}now | date "Mon Jan 2 15:04:05 MST 2006"{{`}}`}}
 
 Wait a minute. We should see today's date. Why didn't it work? It's because the server hasn't yet been configured to evaluate templates! Easy to fix, just add a line to the Caddyfile so it looks like this:
 
-```
+```caddy
 localhost
 
 templates
@@ -118,7 +118,7 @@ With Caddy's [templates module](/docs/modules/http.handlers.templates), you can
 
 It's good practice to compress responses with a quick and modern compression algorithm. Let's enable Gzip and Zstandard support using the [`encode`](/docs/caddyfile/directives/encode) directive:
 
-```
+```caddy
 localhost
 
 encode zstd gzip
@@ -143,7 +143,7 @@ But it is easy to make it so we can add more sites!
 
 Our Caddyfile so far:
 
-```
+```caddy
 localhost
 
 encode zstd gzip
@@ -153,7 +153,7 @@ file_server browse
 
 is equivalent to this one:
 
-```
+```caddy
 localhost {
 	encode zstd gzip
 	templates
@@ -167,7 +167,7 @@ By wrapping our site block in curly braces `{ }` we are able to define multiple,
 
 For example:
 
-```
+```caddy
 :8080 {
 	respond "I am 8080"
 }
@@ -181,7 +181,7 @@ When wrapping site blocks in curly braces, only [addresses](/docs/caddyfile/conc
 
 For multiple sites which share the same configuration, you can add more addresses, for example:
 
-```
+```caddy
 :8080, :8081 {
 	...
 }
@@ -198,7 +198,7 @@ We may want to apply some directives only to certain requests. For example, let'
 
 This config will not work like we want:
 
-```
+```caddy
 localhost
 
 file_server
@@ -207,7 +207,7 @@ reverse_proxy 127.0.0.1:9005
 
 In practice, we may want to use the reverse proxy only for API requests, i.e. requests with a base path of `/api/`. This is easy to do by adding a [matcher token](/docs/caddyfile/matchers#syntax):
 
-```
+```caddy
 localhost
 
 file_server
@@ -232,15 +232,15 @@ First, set an environment variable (in the same shell that runs Caddy):
 
 Then you can use it like this in the Caddyfile:
 
-```
+```caddy
 {$SITE_ADDRESS}
 
 file_server
 ```
 
 Before the Caddyfile is parsed, it will be expanded to:
 
-```
+```caddy
 localhost:9055
 
 file_server
@@ -255,7 +255,7 @@ You can use environment variables anywhere in the Caddyfile, for any number of t
 
 One last thing that you will find most helpful: if you want to remark or note anything in your Caddyfile, you can use comments, starting with `#`:
 
-```
+```caddy
 # this starts a comment
 ```
 

src/docs/markdown/caddyfile.md

@@ -8,7 +8,7 @@ The **Caddyfile** is a convenient Caddy configuration format for humans. It is m
 
 It looks like this:
 
-```
+```caddy
 example.com
 
 root * /var/www/wordpress

src/docs/markdown/caddyfile/concepts.md

@@ -46,7 +46,7 @@ Opening and closing a **block** is done with curly braces:
 
 When there is only one site block, the curly braces (and indentation) are optional. This is for convenience to quickly define a single site, for example, this:
 
-```
+```caddy
 localhost
 
 reverse_proxy /api/* localhost:9001
@@ -55,7 +55,7 @@ file_server
 
 is equivalent to:
 
-```
+```caddy
 localhost {
 	reverse_proxy /api/* localhost:9001
 	file_server
@@ -66,7 +66,7 @@ when you have only a single site block; it's a matter of preference.
 
 To configure multiple sites with the same Caddyfile, you **must** use curly braces around each one to separate their configurations:
 
-```
+```caddy
 example1.com {
 	root * /www/example.com
 	file_server
@@ -84,15 +84,15 @@ If a request matches multiple site blocks, the site block with the most specific
 
 **Directives** are keywords which customize how the site is served. For example, a complete file server config might look like this:
 
-```
+```caddy
 localhost
 
 file_server
 ```
 
 Or a reverse proxy:
 
-```
+```caddy
 localhost
 
 reverse_proxy localhost:9000
@@ -104,7 +104,7 @@ In the second example, `localhost:9000` is an **argument** because it appears on
 
 **Subdirectives** can appear in directive blocks:
 
-```
+```caddy
 localhost
 
 reverse_proxy localhost:9000 localhost:9001 {
@@ -121,21 +121,21 @@ The Caddyfile is lexed into tokens before being parsed. Whitespace is significan
 
 Often, directives expect a certain number of arguments; if a single argument has a value with whitespace, it would be lexed as two separate tokens:
 
-```
+```caddy-d
 directive abc def
 ```
 
 This could be problematic and return errors or unexpected behavior.
 
 If `abc def` is supposed to be the value of a single argument, it needs to be quoted:
 
-```
+```caddy-d
 directive "abc def"
 ```
 
 Quotes can be escaped if you need to use quotes in quoted tokens, too:
 
-```
+```caddy-d
 directive "\"abc def\""
 ```
 
@@ -172,13 +172,13 @@ Wildcards (`*`) may be used, but only to represent precisely one label of the ho
 
 If multiple sites share the same definition, you can list all of them together:
 
-```
+```caddy
 localhost:8080, example.com, www.example.com
 ```
 
 or
 
-```
+```caddy
 localhost:8080,
 example.com,
 www.example.com
@@ -198,7 +198,7 @@ Request matchers can be used to classify requests by a given criteria. This conc
 
 For directives that support matchers, the first argument after the directive is the **matcher token**. Here are some examples:
 
-```
+```caddy-d
 root *           /var/www  # matcher token: *
 root /index.html /var/www  # matcher token: /index.html
 root @post       /var/www  # matcher token: @post
@@ -241,7 +241,7 @@ You can use any [Caddy placeholders](/docs/conventions#placeholders) in the Cadd
 
 You can define special blocks called snippets by giving them a name surrounded in parentheses:
 
-```
+```caddy
 (redirect) {
 	@http {
 		scheme http
@@ -252,7 +252,7 @@ You can define special blocks called snippets by giving them a name surrounded i
 
 And then you can reuse this anywhere you need:
 
-```
+```caddy-d
 import redirect
 ```
 
@@ -264,7 +264,7 @@ The `import` directive can also be used to include other files in its place. As
 
 Comments start with `#` and proceed until the end of the line:
 
-```
+```caddy-d
 # Comments can start a line
 directive  # or go at the end
 ```
@@ -276,7 +276,7 @@ The hash character `#` cannot appear in the middle of a token (i.e. it must be p
 
 If your configuration relies on environment variables, you can use them in the Caddyfile:
 
-```
+```caddy
 {$SITE_ADDRESS}
 ```
 
@@ -289,7 +289,7 @@ If you want to defer the substitution of an environment variable until runtime,
 
 A Caddyfile may optionally start with a special block that has no keys, called a [global options block](/docs/caddyfile/options):
 
-```
+```caddy
 {
 	...
 }

src/docs/markdown/caddyfile/directives.md

@@ -35,7 +35,7 @@ Directive | Description
 
 The syntax of each directive will look something like this:
 
-```
+```caddy-d
 directive [<matcher>] <args...> {
 	subdirective [<args...>]
 }
@@ -54,7 +54,7 @@ Subdirectives are always optional unless documented otherwise, even though they
 
 Most---but not all---directives accept [matcher tokens](/docs/caddyfile/matchers#syntax), which let you filter requests. Matcher tokens are usually optional. If you see this in a directive's syntax:
 
-```
+```caddy-d
 [<matcher>]
 ```
 
@@ -67,7 +67,7 @@ Because matcher tokens all work the same, the various possibilities for the matc
 
 Many directives manipulate the HTTP handler chain. The order in which those directives are evaluated matters, so a default ordering is hard-coded into Caddy:
 
-```
+```caddy-d
 root
 
 header

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

@@ -15,7 +15,7 @@ Caddy configuration does not accept plaintext passwords; you MUST hash them befo
 
 ## Syntax
 
-```
+```caddy-d
 basicauth [<matcher>] [<hash_algorithm>] {
 	<username> <hashed_password_base64> [<salt_base64>]
 	...
@@ -32,7 +32,7 @@ basicauth [<matcher>] [<hash_algorithm>] {
 
 Protect all resources in /secret so only Bob can access them with the password "hiccup":
 
-```
+```caddy-d
 basicauth /secret/* {
 	Bob JDJhJDEwJEVCNmdaNEg2Ti5iejRMYkF3MFZhZ3VtV3E1SzBWZEZ5Q3VWc0tzOEJwZE9TaFlZdEVkZDhX
 }

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

@@ -11,7 +11,7 @@ Note that binding sites inconsistently may result in unintended consequences. Fo
 
 ## Syntax
 
-```
+```caddy-d
 bind <hosts...>
 ```
 
@@ -22,12 +22,12 @@ bind <hosts...>
 
 To make a socket accessible only on the current machine, bind to the loopback interface (localhost):
 
-```
+```caddy-d
 bind 127.0.0.1
 ```
 
 To include IPv6:
 
-```
+```caddy-d
 bind 127.0.0.1 ::1
 ```

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

@@ -8,7 +8,7 @@ Encodes responses using the configured encoding(s). A typical use for encoding i
 
 ## Syntax
 
-```
+```caddy-d
 encode [<matcher>] <formats...> {
 	gzip [<level>]
 	zstd
@@ -24,13 +24,13 @@ encode [<matcher>] <formats...> {
 
 Enable Gzip compression:
 
-```
+```caddy-d
 encode gzip
 ```
 
 Enable Zstandard and Gzip compression:
 
-```
+```caddy-d
 encode zstd gzip
 ```