@obito using the example.com host would send traffic back outside the cluster, rather than directly to the in-cluster service, wouldn't it? in your case with Wordpress, is it necessary to do that (maybe so Wordpress can serve up the right site)?

if is is necessary, we could add a field to the HTTPScaledObject to enable it.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

This issue has been automatically closed due to inactivity.

I believe I am experiencing this same issue. We have a Ruby on Rails based web application and we are experimenting with the http-add-on to scale the pods. I believe we have configured everything properly, but redirects are getting mangled by the interceptor.

For example, when the user is logged in, the root path automatically redirects to /dashboard. However, when routing traffic through the interceptor, it is redirected like this:

https://app.example.com ➡️ https://app-service:3000/dashboard

Using the http-add-on to scale a Rails (or Wordpress) app seems like a use case that should be supported. I'm unsure if it is related, but I also stumbled upon this issue which discusses redirects: #249.

@arschles is there a bug here? Or is this expected behavior? Or, do you believe @obito or I have misconfigured the http-add-on?

I believe I am experiencing this same issue. We have a Ruby on Rails based web application and we are experimenting with the http-add-on to scale the pods. I believe we have configured everything properly, but redirects are getting mangled by the interceptor.

For example, when the user is logged in, the root path automatically redirects to /dashboard. However, when routing traffic through the interceptor, it is redirected like this:

https://app.example.com ➡️ https://app-service:3000/dashboard

Using the http-add-on to scale a Rails (or Wordpress) app seems like a use case that should be supported. I'm unsure if it is related, but I also stumbled upon this issue which discusses redirects: #249.

@arschles is there a bug here? Or is this expected behavior? Or, do you believe @obito or I have misconfigured the http-add-on?

Hi, do you have by any chance Apache/NGINX running in your Rails pod, or changing the "Host" in your app?

HTTP-Add-On seems to change the Host header to http://service:port, so you must use the X-Forwarded-Host header. WordPress was reading the Host header, and redirecting to http://service:port/path. My guess would be that your Rails app is using this Host header to redirect.

I fixed that by adding this in my Apache Config:

### value X-Forwarded-Host written in TempValue. 
SetEnvIf X-Forwarded-Host ".+" TempValue=$0

### replace "Host" header by X-Forwarded-Host
RequestHeader set Host %{TempValue}e env=TempValue

Hope it helps you!

Hey @obito - thanks for following up here. Really appreciate it.

Unfortunately, we do not have Apache or NGINX in front of our rails pods. Seems like a decent workaround, but a workaround nonetheless.

@arschles - can you reopen this issue? The use-case here seems like the most basic one. In what scenario is this not a problem?

Hey folks - I'm not sure I'm understanding. The purpose of the interceptor is to map the host of an incoming request (the host in the URL or the Host header) to an internal URL of a Service on a specified port in a specified namespace. As of version 0.3.0, that would map something like example.com to a URL that looks like this: <service name>.<namespace>:<port>.

Are you looking for the interceptor to not change the Host header when it forwards the request, or are you looking for the interceptor to restore the original host header when sending a redirect back to the client (or something else)?

Regardless, reopening this issue and putting it into our next milestone.

Hey @arschles - thanks for your reply and for re-opening this issue.

Are you looking for the interceptor to not change the Host header when it forwards the request, or are you looking for the interceptor to restore the original host header when sending a redirect back to the client (or something else)?

The former, I think! My expectation was that the interceptor would be completely transparent. The service/application on the other side of the interceptor should be completely unaware that the request was proxied by the interceptor. Preserving the original host is important to most web application frameworks, at least if the goal is to have the http-add-on work "out of the box".

Is there harm that could come from preserving the original host header? What's the purpose or value of changing it? All honest questions here, just trying to understand the situation better.

Is there harm that could come from preserving the original host header? What's the purpose or value of changing it?

@benjaminwood certainly not. I think this is a bug, and I'll go look into it now.

Thanks both for bringing this up, and for doing so in such a nice way 😄

Please see #404 for a proposed solution to this problem.

Hi @tomkerkhove - just wondering what's the status, since you reopened, moved and removed this from the Roadmap... it's a big issue for anyone using redirection down the road