Browse Source

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
master
Matthew Holt 5 years ago
parent
commit
2a8a198568
No known key found for this signature in database GPG Key ID: 2A349DD577D586A5
  1. 12
      modules/caddyhttp/reverseproxy/reverseproxy.go

12
modules/caddyhttp/reverseproxy/reverseproxy.go

@ -441,12 +441,14 @@ func (h Handler) prepareRequest(req *http.Request) error {
req.Header.Set("X-Forwarded-For", clientIP)
}
// set X-Forwarded-Proto; many backend apps expect this too
proto := "https"
if req.TLS == nil {
proto = "http"
if req.Header.Get("X-Forwarded-Proto") == "" {
// set X-Forwarded-Proto; many backend apps expect this too
proto := "https"
if req.TLS == nil {
proto = "http"
}
req.Header.Set("X-Forwarded-Proto", proto)
}
req.Header.Set("X-Forwarded-Proto", proto)
return nil
}

Loading…
Cancel
Save