docs: A bunch more additions since v2.3.0

I went through the whole list of commits here: https://github.com/caddyserver/caddy/compare/v2.3.0...ec3ac84

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

@@ -18,6 +18,8 @@ Proxies requests to one or more backends with configurable transport, load balan
   - [The `fastcgi` tranport](#the-fastcgi-transport)
 - [Examples](#examples)
 
+
+
 ## Syntax
 
 ```caddy-d
@@ -38,6 +40,9 @@ reverse_proxy [<matcher>] [<upstreams...>] {
     health_timeout  <duration>
     health_status   <status>
     health_body     <regexp>
+	health_headers {
+		<field> [<values...>]
+	}
 
     # passive health checking
     fail_duration     <duration>
@@ -49,6 +54,8 @@ reverse_proxy [<matcher>] [<upstreams...>] {
     # streaming
     flush_interval <duration>
     buffer_requests
+	buffer_responses
+	max_buffer_size <size>
 
     # header manipulation
     header_up   [+|-]<field> [<value|regexp> [<replacement>]]
@@ -61,6 +68,8 @@ reverse_proxy [<matcher>] [<upstreams...>] {
 }
 ```
 
+
+
 ### Upstreams
 
 - **&lt;upstreams...&gt;** is a list of upstreams (backends) to which to proxy.
@@ -84,6 +93,8 @@ Additionally, upstream addresses cannot contain paths or query strings, as that
 
 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
 
 Load balancing is used whenever more than one upstream is defined.
@@ -102,6 +113,8 @@ Load balancing is used whenever more than one upstream is defined.
 - **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, this retry is disabled. Clients will wait for up to this long while the load balancer tries to find an available upstream host.
 - **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.
 
+
+
 #### Active health checks
 
 Active health checks perform health checking in the background on a timer:
@@ -112,6 +125,9 @@ Active health checks perform health checking in the background on a timer:
 - **health_timeout** is a [duration value](/docs/conventions#durations) that defines how long to wait for a reply before marking the backend as down.
 - **health_status** is the HTTP status code to expect from a healthy backend. Can be a 3-digit status code or a status code class ending in `xx`, for example: `200` (default) or `2xx`.
 - **health_body** is a substring or regular expression to match on the response body of an active health check. If the backend does not return a matching body, it will be marked as down.
+- **health_headers** allows specifying headers to set on the active health check requests. This is useful if you need to change the `Host` header, or if you need to provide some authentication to your backend as part of your health checks.
+
+
 
 #### Passive health checks
 
@@ -123,12 +139,18 @@ Passive health checks happen inline with actual proxied requests:
 - **unhealthy_latency** is a [duration value](/docs/conventions#durations) that counts a request as failed if it takes this long to get a response.
 - **unhealthy_request_count** is the permissible number of simultaneous requests to a backend before marking it as down.
 
+
+
 ### Streaming
 
 The proxy **buffers responses** by default for wire efficiency:
 
 - **flush_interval** is a [duration value](/docs/conventions#durations) that defines how often Caddy should flush the buffered response body to the client. Set to -1 to disable buffering. It is set to -1 automatically for requests that have a `text/event-stream` response or for HTTP/2 requests where the Content-Length is unspecified.
 - **buffer_requests** will cause the proxy to read the entire request body into a buffer before sending it upstream. This is very inefficient and should only be done if the upstream requires reading request bodies without delay (which is something the upstream application should fix).
+- **buffer_responses** will cause the entire response body to be read and buffered in memory before being proxied to the client. This should be avoided if at all possible for performance reasons, but could be useful if the backend has tighter memory constraints.
+- **max_buffer_size** if body buffering is enabled, this sets the maximum size of the buffers used for the requests and responses. This accepts all size formats supported by [go-humanize](https://github.com/dustin/go-humanize/blob/master/bytes.go).
+
+
 
 ### Headers
 
@@ -144,6 +166,8 @@ By default, Caddy passes thru incoming headers to the backend&mdash;including th
 
 Since these header fields are only de-facto standards, Caddy may stop setting them implicitly in the future if the standardized [Forwarded](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Forwarded) header field becomes more widely adopted.
 
+
+
 ### Transports
 
 Caddy's proxy **transport** is pluggable:
@@ -222,6 +246,7 @@ transport fastcgi {
 - **write_timeout** is how long to wait when sending to the FastCGI server. Accepts [duration values](/docs/conventions#durations). Default: no timeout.
 
 
+
 ## Examples
 
 Reverse proxy all requests to a local backend:

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

@@ -23,6 +23,7 @@ tls [internal|<email>] | [<cert_file> <key_file>] {
 	ca        <ca_dir_url>
 	ca_root   <pem_file>
 	dns       <provider_name> [<params...>]
+	resolvers <dns_servers...>
 	eab       <key_id> <mac_key>
 	on_demand
 	client_auth {
@@ -70,6 +71,7 @@ tls [internal|<email>] | [<cert_file> <key_file>] {
 - **ca** changes the ACME CA endpoint. This is most often used to set [Let's Encrypt's staging endpoint](https://letsencrypt.org/docs/staging-environment/) when testing, or an internal ACME server. (To change this value for the whole Caddyfile, use the `acme_ca` [global option](/docs/caddyfile/options) instead.)
 - **ca_root** specifies a PEM file that contains a trusted root certificate for the ACME CA endpoint, if not in the system trust store.
 - **dns** enables the [DNS challenge](/docs/automatic-https#dns-challenge) using the specified provider plugin, which must be plugged in from one of the [caddy-dns](https://github.com/caddy-dns) repositories. Each provider plugin may have their own syntax following their name; refer to their docs for details. Maintaining support for each DNS provider is a community effort. [Learn how to enable the DNS challenge for your provider at our wiki.](https://caddy.community/t/how-to-use-dns-provider-modules-in-caddy-2/8148)
+- **resolvers** customizes the DNS resolvers used when performing the DNS challenge; these take precedence over system resolvers or any default ones. If set here, the resolvers will propagate to all configured certificate issuers.
 - **eab** configures ACME external account binding (EAB) for this site, using the key ID and MAC key provided by your CA.
 - **on_demand** enables [on-demand TLS](/docs/automatic-https#on-demand-tls) for the hostnames given in the site block's address(es).
 - **client_auth** enables and configures TLS client authentication:
@@ -102,7 +104,7 @@ These issuers come standard with the `tls` directive:
 Obtains certificates using the ACME protocol.
 
 ```caddy
-... acme {
+... acme [<directory_url>] {
 	dir      <directory_url>
 	test_dir <test_directory_url>
 	email    <email>

src/docs/markdown/caddyfile/options.md

@@ -49,6 +49,7 @@ Possible options are:
 	}
 	key_type ed25519|p256|p384|rsa2048|rsa4096
 	cert_issuer <name> ...
+	ocsp_stapling off
 
 	# Server Options
 	servers [<listener_address>] {
@@ -134,7 +135,10 @@ Configures [On-Demand TLS](/docs/automatic-https#on-demand-tls) where it is enab
 Specifies the type of key to generate for TLS certificates; only change this if you have a specific need to customize it.
 
 ##### `cert_issuer`
-Defines the issuer (or source) of TLS certificates. The tokens following the name of the issuer set up the issuer the same as if specified in the [`tls` directive](/docs/caddyfile/directives/tls#issuer).
+Defines the issuer (or source) of TLS certificates. The tokens following the name of the issuer set up the issuer the same as if specified in the [`tls` directive](/docs/caddyfile/directives/tls#issuer). May be repeated if you wish to configure more than one issuer to try. They will be tried in the order they are defined.
+
+##### `ocsp_stapling`
+Can be set to `off` to disable OCSP stapling. Useful in environments where responders are not reachable due to firewalls.
 
 
 

src/docs/markdown/command-line.md

@@ -222,7 +222,8 @@ NOTE: Due to [a bug in Go](https://github.com/golang/go/issues/29228), version i
 <pre><code class="cmd bash">caddy reload
 	[--config &lt;path&gt;]
 	[--adapter &lt;name&gt;]
-	[--address &lt;interface&gt;]</code></pre>
+	[--address &lt;interface&gt;]
+	[--force]</code></pre>
 
 Gives the running Caddy instance a new configuration. This has the same effect as POSTing a document to the [/load endpoint](/docs/api#post-load), but this command is convenient for simple workflows revolving around config files. Compared to the `stop`, `start`, and `run` commands, this single command is the correct, semantic way to change/reload the running configuration.
 
@@ -234,6 +235,8 @@ Because this command uses the API, the admin endpoint must not be disabled.
 
 `--address` needs to be used if the admin endpoint is not listening on the default address and if it is different from the address in the provided config file. Note that only TCP addresses are supported at this time.
 
+`--force` will cause a reload to happen even if the specified config is the same as the one the running Caddy instance is already using. Can be useful to force Caddy to reload TLS certificate files specified to load in the config, if they've become stale.
+
 
 
 ### `caddy reverse-proxy`