Skip to content
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

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

arschles
Copy link
Collaborator

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, a Location header will be returned to the client with the proper hostname in it.

Checklist

Fixes #331

Signed-off-by: Aaron Schlesinger <aaron@ecomaz.net>
@arschles arschles added this to the v0.4.0 milestone Feb 18, 2022
arschles and others added 2 commits February 18, 2022 13:57
@arschles
Copy link
Collaborator Author

@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

@benjaminwood
Copy link

I'll try it out and follow up!

@arschles
Copy link
Collaborator Author

@benjaminwood thank you kindly!

@tomkerkhove tomkerkhove removed this from the v0.4.0 milestone May 11, 2022
@obito
Copy link

obito commented Oct 31, 2022

Any follow up on this ?

@proligde
Copy link

proligde commented May 9, 2023

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Proxy redirection to the wrong URL
6 participants