reverseproxy: Don't overwrite existing X-Forwarded-Proto header

Correct behavior is not well defined because this is a non-standard header field. This could be a "hop-by-hop" field much like X-Forwarded-For is, but even our X-Forwarded-For implementation preserves prior entries. Or, it could be best to preserve the original value from the first hop, representing the protocol as facing the client. Let's try it the other way for a bit and see how it goes. See https://caddy.community/t/caddy2-w-wordpress-behind-nginx-reverse-proxy/8174/3?u=matt

Matthew Holt committed May 20, 2020 at 11:33 UTC 2a8a19856858dcaaf8d3233a2fc701e8a10c84a4

1 file changed +7 -5

modules/caddyhttp/reverseproxy/reverseproxy.go

+7 -5

@@ -441,12 +441,14 @@ func (h Handler) prepareRequest(req *http.Request) error {

441 req.Header.Set("X-Forwarded-For", clientIP)

442 }

443

444 - // set X-Forwarded-Proto; many backend apps expect this too

445 - proto := "https"

446 - if req.TLS == nil {

447 - proto = "http"

444 + if req.Header.Get("X-Forwarded-Proto") == "" {

445 + // set X-Forwarded-Proto; many backend apps expect this too

446 + proto := "https"

447 + if req.TLS == nil {

448 + proto = "http"

449 + }

450 + req.Header.Set("X-Forwarded-Proto", proto)

451 }

449 - req.Header.Set("X-Forwarded-Proto", proto)

452

453 return nil

454 }