Caddyfile.template incorrect configuration cause infinite redirect

[heimoshuiyu]

According to caddy's doc https://caddyserver.com/docs/caddyfile/directives/reverse_proxy#defaults

By default, Caddy passes through incoming headers—including Host—to the backend without modifications, with three exceptions:

• It sets or augments the X-Forwarded-For header field.
• It sets the X-Forwarded-Proto header field.
• It sets the X-Forwarded-Host header field.

For these X-Forwarded-* headers, by default, the proxy will ignore their values from incoming requests, to prevent spoofing.

But the Caddyfile.template set these two header incorrectly

openproject-docker-compose/proxy/Caddyfile.template

Lines 10 to 11 in 9104e06

	header_up X-Forwarded-Proto {header.X-Forwarded-Proto}
	header_up X-Forwarded-For {header.X-Forwarded-For}

Causing the web frontend received the following data, then frontend return 301 redirect to https://openproject.local:8043 infinitely.

Listening on 0.0.0.0 8080
Connection received on 10.89.3.6 58158
GET / HTTP/1.1
Host: openproject.local:8043
User-Agent: curl/8.14.1
Accept: */*
Via: 2.0 Caddy
X-Forwarded-For: 
X-Forwarded-Host: openproject.local:8043
X-Forwarded-Proto: 
Accept-Encoding: gzip

After remove these two header_up lines, reverse_proxy works as except:

Listening on 0.0.0.0 8080
Connection received on 10.89.3.7 59848
GET / HTTP/1.1
Host: openproject.local:8043
User-Agent: curl/8.14.1
Accept: */*
Via: 2.0 Caddy
X-Forwarded-For: 10.89.3.7
X-Forwarded-Host: openproject.local:8043
X-Forwarded-Proto: https
Accept-Encoding: gzip

[heimoshuiyu]

Oh, I figured it out. This configuration is for caddy located behind another reverse proxy. I think this situation a bit weird, since caddy itself can terminate ssl, why would you need 2 reverse proxies?