How can I get the X-Forwarded-Proto HTTP header?
The ADC-as-a-Service / Cloud Load Balancer does not send the X-Forwarded-Proto HTTP header. However, we have one of our own that will give you the information you’re looking for as well as the IP address the user connected on. So while it’s not exactly what you’re looking for, it gets the job done with a bonus too!
First, a little background
Typically, the X-Forwarded-Proto HTTP header will send something like “http” or “https” in the request so you know whether it came into your application encrypted or not. This is useful for web applications, but since the ADC-as-a-Service does way more than basic web apps, we thought it would be handy to have a more detailed header, so we created the HTTP IP and Port Header.
Enabling the HTTP IP and Port Header
In the public facing port options dialog box, you will see an option at the top labeled “Insert HTTP IP and Port Header” as shown in the image below. This is available for HTTP and SSL protocol types. We cannot insert any header into encrypted traffic or non-HTTP traffic, so SSL_PROXY is not an option, as is regular TCP.
When you check the box, you can enter your own header name for it. You could put X-Forwarded-Proto in here if you like, but we recommend something unique for your purposes. Not only is our header different than the traditional one, but a unique name also ensures someone can’t spoof the value by adding the header on their request.
When enabled, the header will be added on requests sent to your device/server towards your application. It will look something like this (depending on what name you entered):
vip-header: 203.0.113.113_443
The first part is the name of the header you created. After the colon is the IP address of your pack/config that the user hit. This is handy if you have the same server/device in multiple packs. Then after the IP is an underscore and the number of the port they connected on. In my example above it is 443, but it might be 80 as well. These are the two most common. But if you’re running your application over any other port, it would show there too.
Occasionally we’ll receive a question as to why it is necessary to know the port the user connected on when ports are mapped directly, for example 443 > 443 and 80 > 80. But because our system allows for port mismatch, such as 443 > 80 to perform SSL offload, if all traffic comes in via the same port, you wouldn’t know which they actually connected on. This could be useful to perform a redirect to https or some other action.
If you have any questions about implementation, do not hesitate to reach out to us. We’re here to help!