Support X-Forwarded-Proto Header for Device URL

Please add support for the x-forwarded-proto header so that when an application is running behind the proxy and accessed using the device url, the app can determine the protocol used to connect to it.

Thank you for this feature request! I will forward it to the team to find out exactly which component the implementation belongs to, and to add it to our regular feature discussions and triaging.

1 Like

My question isn’t about plugging all this up. It works great, and I’m honestly blown away at how straight forward it has been to set this up. I’ll also add that HTTP clients connect directly to haproxy, thereby bypassing the SSL offloaded. And for the record, there are redundant partners for each of the above pieces. The problem is somewhat abstract. I’ll start with a demonstration. The client makes a request through the setup to https://myserver.tld/scp (some headers removed to keep things clear)

Hi @regedad, it seems like your question is incomplete? Can you please elaborate?

Hi @deisterhold,

I’ve taken a look at this and unfortunately it is not possible given our setup. We terminate SSL at our layer 4 load balancers so by the time the Proxy service is handling the request it believes it is handling a http request, so the X-Forwarded-Proto would be reported as http. There are various reasons why we do not/cannot operate the load balancers at layer 7 (which would allow them to insert the appropriate X-Forwarded-* headers) but it boils down to a requirement to use ProxyProtocol between the Load Balancers and the Proxy service.