Caddy as reverse proxy is serving 302 status code with the new location to the client

1. Output of caddy version:

2.4.6

2. How I run Caddy:

With caddy file.

a. System environment:

docker

d. My complete Caddy config:

localhost { 
	rewrite * /slate-easypnr-api-v3{uri} 
	
	reverse_proxy easypnr.github.io  { 
			header_up Host {upstream_hostport} 
			header_up X-Forwarded-Host {host}
	}
}

3. The problem I’m having:

Github.io answers caddy with a 302 redirect with a new location. Caddy is returning the URL to the browser instead of following it and returning the end content.

Question: How can I fine control these redirects from the upstream server? Sometimes it will make sense to follow the new location (location in different url), sometimes it does not and I will need to serve the content transparently to the user without taking him to another URL.

I could not find documentation about it.

4. Error messages and/or full log output:

No error.

5. What I already tried:

If I change the upstream url to have https it servers correctly:
I could let it with https, but I want to learn more about caddy and also control better these redirects, because more of this can happen with other websites.

localhost { 
	rewrite * /slate-easypnr-api-v3{uri} 
	
	reverse_proxy https://easypnr.github.io  { 
			header_up Host {upstream_hostport} 
			header_up X-Forwarded-Host {host}
	}
}

Following redirects is not supported with reverse_proxy. It doesn’t make sense to support because it’s wasteful roundtrips.

Just configure Caddy with the correct protocol. That’s it.

Please upgrade to v2.5.2, you don’t need to add the X-Forwarded-Host header anymore, Caddy does it for you in the latest version.

Fair enough Francis!

So, any 301 or 302 response with a new location that caddy gets from the upstream server will replace entirely the URL in the browser (browsers follows it) and the user will be moved out from my domain?

PS: I will upgrade caddy.

The thing is that upstream apps typically want to respond to the client with redirects. Imagine the user hits some page which requires being logged in, then it would send a redirect to send the user to the /login page. If reverse_proxy followed redirects, then it would break this completely.

Proxying over HTTP requests to a server which responds with HTTP->HTTPS redirects doesn’t make sense. You must proxy over HTTPS in that case. There’s no way around it.

2 Likes

This topic was automatically closed after 14 days. New replies are no longer allowed.