-
Notifications
You must be signed in to change notification settings - Fork 103
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
Ensuring that the proper host is set on all Location headers #404
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Aaron Schlesinger <[email protected]>
Signed-off-by: Aaron Schlesinger <[email protected]>
@obito @benjaminwood here is a proposed solution to #331. A short overview of what this is doing is in the description of the PR above. is in the Can you folks take a look and let me know what you think? An alternative to this PR is to avoid overwriting the request host here (similar to something you suggested @obito). I'd like to hear what you both think about that also, if you don't mind. cc/ @asw101 |
I'll try it out and follow up! |
@benjaminwood thank you kindly! |
Any follow up on this ? |
@arschles Hi! I just stumbled across this issue and instead of opening a new one, it might make sense to follow up on this one first: I think I have a scenario where the original host header should have been kept while forwarding the request to the target pod: I have a web service that is hostname-aware and changes behavior based on it. Unfortunately it cannot be configured to use the x-forwarded-for header, which indeed contains the correct, original request hostname. For example: My original request was https://foo.bar.com. Without KEDA (Only with nginx ingress) my target pod sees "foo.bar.com" as the hostname (no x-forwarded-for header is set). After enabling KEDA with the http-add-on the target pod only sees "foo.default". Is there a way to configure that behavior so the proxy preserves the original hostname? Thanks in advance - max |
This PR changes the behavior of the interceptor when the app returns a
Location
header that does not have a host on it (i.e.Location: "/abc"
).Prior to this patch, the interceptor simply passed this value back to the client, but now, it ensures that the incoming host value is prepended to the final header. This new behavior ensures that in all circumstances where an app intends to return a
Location
header, aLocation
header will be returned to the client with the proper hostname in it.Checklist
README.md
docs/
directoryFixes #331