-
Notifications
You must be signed in to change notification settings - Fork 90
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proxy redirection to the wrong URL #331
Comments
@obito using the if is is necessary, we could add a field to the |
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
Using the @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 I fixed that by adding this in my Apache Config:
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 Are you looking for the interceptor to not change the Regardless, reopening this issue and putting it into our next milestone. |
Hey @arschles - thanks for your reply and for re-opening this issue.
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. |
@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 |
Interceptor redirect to
http://service:80/path
instead ofhttp://url.com/path
Expected Behavior
Redirect to
http://url.com/path
Actual Behavior
Redirect from
http://url.com
tohttp://service:80/path
Steps to Reproduce the Problem
http://example.com
) and it will redirect tohttp://service:80
Specifications
A way to fix it would be to specify the correct host on the forwardRequest function instead of giving the service host. I don't really get why you don't use the host instead of the service url? (here)
We are basically setting fake host, so that's why WordPress is not able to redirect correctly. As a workaround, we use
HTTP_X_FORWARDED_HOST
header to get the correct host.The text was updated successfully, but these errors were encountered: