From 874270a9bcfd0f4263adc8fac99cc7aa4fcd5cf3 Mon Sep 17 00:00:00 2001 From: David Baynard Date: Mon, 9 Jun 2025 17:19:44 +0200 Subject: [PATCH] docs: clarify limitation around reverse_proxy (#457) * docs: clarify limitation around reverse_proxy * docs: clarify Host header requirements wrt TLS The previous documentation was clear on handling http->https proxying, but not the other way round. They did not cover the case of proxying to a unix socket, either. There are special considerations when proxying to caddy in either of these cases, that should be mentioned. --- src/docs/markdown/caddyfile/directives/reverse_proxy.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/docs/markdown/caddyfile/directives/reverse_proxy.md b/src/docs/markdown/caddyfile/directives/reverse_proxy.md index 36ceaaa..9d96b2b 100644 --- a/src/docs/markdown/caddyfile/directives/reverse_proxy.md +++ b/src/docs/markdown/caddyfile/directives/reverse_proxy.md @@ -493,6 +493,8 @@ reverse_proxy https://example.com { The `X-Forwarded-Host` header is still passed [by default](#defaults), so the upstream may still use that if it needs to know the original `Host` header value. +The same applies when terminating TLS in caddy and proxying via HTTP, whether to a port or a unix socket. Indeed, caddy itself must receive the correct Host, when it is the target of `reverse_proxy`. In the unix socket case, the `upstream_hostport` will be the socket path, and the Host must be set explicitly. + ## Rewrites @@ -692,6 +694,7 @@ Three placeholders will be made available within the `handle_response` routes: - `{rp.header.*}` The headers from the backend's response. +While the reverse proxy response handler can copy the new response received from the proxy back to the client, it cannot pass on that new response to a subsequent reverse proxy. Every use of `reverse_proxy` receives the body from the original request (or as modified with a different module).