Location Header Rewriting for HTTP Targets

[micchickenburger]

Is your feature request related to a problem? Please describe. Yes. If an application server sends a HTTP 301, 302, or 303 redirect, the ephemeral destination port used by the client is not included. This causes the client browser to navigate to the wrong resource. For example, imagine the following:

Client (TCP/54321) > Boundary Worker > ALB (80) > App Server > nginx (80)

The client navigates to / and the application sends a 302 redirect to /login. From Nginx's perspective, the request port from the ALB is 80. And the ALB passes header X-Forwarded-Port which is also 80. So the header reads Location: http://127.0.0.1/login. The location header needs to be modified to include the ephemeral port being used by the client.

I've looked through the docs, discussion forum, and GitHub issues but couldn't find any mention of this issue yet. I also created a question on the discussion forum: https://discuss.hashicorp.com/t/http-301-302-and-303-redirects-with-ephemeral-ports/28217

Describe the solution you'd like Boundary workers should update the Location header in the response to ensure client browsers will navigate to the URI over the correct ephemeral port established by Boundary. An alternative I suppose could be to send a X-BOUNDARY-PORT header, which nginx could use to do location header rewriting.

I'm also not sure how this could work with HTTPS.

[jefferai]

We don't have http targets right now so really you have to think about it from a tcp standpoint -- it's a connection, and the fact that it's HTTP on top and being given a bad address is opaque to Boundary.

Generally speaking an app that does a redirect doesn't modify the host/port, so if your app was speaking directly to your client it'd probably be fine. The issue is the layers in between. If you can't remove them, maybe you can figure out a way to configure ALB or the other jumps to preserve the original port.

When we have http targets, which we will eventually but don't yet, we should be able to handle this kind of thing transparently. Unfortunately, we're just not there yet.

CCing @PPacent for visibility.

[micchickenburger]

Thanks for your reply. We learned that the web server we were using (WEBrick) incorrectly writes all relative redirects as absolute. I've opened an issue to have it corrected but in the meantime we switched to Puma. I hope that's helpful for others who might run into this issue.

[jefferai]

Glad you got a workaround! I'm going to keep this open until @PPacent closes it to make sure it's something he's tracking.

[covetocove]

Closing this issue as there haven't been any other upvotes and @micchickenburger found a workaround.