Forum Discussion
Dennis_Andrade_
Nimbostratus
NimbostratusHTTP profile: x-forwarded-proto
I have a virtual server configured on a custom port 8080 with a client SSL profile attached to it. So the user will enter https://hostname.com:8080 to access the virtual server. So far so good. I have a HTTP profile attached to this virtual server and I need to use the x-forwarded-proto. That being said, if I use x-forwarded-proto:https, my connections to the assigned pools fail because the server tries to connect to https://hostname.com without the custom port. What should I set the x-forwarded-proto:???? value to in order for the http requests to keep both the protocol and the custom port at the end?
- Kevin_Stewart
Employee
The X-Forwarded-Proto header is typically used to tell an application that SSL is being offloaded by a proxy. This may be important when an application doesn't understand the SSL offloading and responds to the client with references to itself (redirects, document object references, etc.) with the URL that it "thinks" it is (usually a web server not listening on an SSL port). It's also important to note that not every application supports or understands this header, nor do all applications have a problem with something else doing the SSL offloading. That said, it's very likely that your application DOES understand this header, but is blindly responding with references to itself by simply changing http:// to https://. There are a few ways to get around this:
-
The most common approach, and probably the easiest, is simply to use a standard port for HTTPS traffic (443). The https:// references from the server will then be correct.
-
You could apply a STREAM profile in an iRule, attached to the VIP, to replace any instance of https://hostname with https://hostname:8080 in the web server's responses.
-
Dennis_Andrade_Option 2 is the best one to go with but I'm little confused on the STREAM profile. Let's say my public URL for the users to access the VIP is https://publichost.com:8080 Then after the user login they are taken to the backend server pool but it fails because it removed the port number: https://publichost.com/backendURI/
In the STREAM profile I added the following to the "target" field (did not use iRule):
@https://publichost.com@https://publichost.com:8080@
Accessing that URL after the change I'm able to login but getting to the backend server gives me an error message right away: The server did not return a response for this request. Not sure I setup the STREAM profile correctly
- Kevin_Stewart
You'll want to do a stream in an iRule. The profile itself applies the stream expression to both directions of traffic, where you only want to affect response traffic. There's been a few of these conditions recently, so I'll refer you to this post for an example:
https://devcentral.f5.com/questions/need-help-with-irule-masking-the-url-please
I would also argue that in most cases option 1 is the easier and more universal action. Port 443 is the default for https, so users wouldn't have to remember to add the :8080 port to the address.
daboochmeisterCirrus
Old topic, but stumbled across it - I've been finding more and more frameworks/apps responding to an X-Forwarded-Port header as well, and using that when constructing redirect or content URLs.
