2

I have an IIS reverse-proxy set up on my dev box to test how my app treats requests that have gone through SSL offloading.
My application needs to recreate the original request, append some query string params, and send it back to the client. By default, IIS/ARR/URL-rewrite does not seem to append the industry standard "X-Forwarded-Host" and "X-Forwarded-Proto" headers. Instead, the closest things I can find are "X-ARR-SSL" and "X-Forwarded-For".
I am happy to parse out the original IP from "X-Forwarded-For", but when I look at the port, it does not seem to make any sense. My SSL reverse-proxy is set up to listen on the default SSL port (443), but the port specified in the header is 52585.
My question is does anyone know how to figure out what the target port of the original request is? I want my application to be able to handle requests proxied by IIS robustly, but it looks like I'm going to have to guess at the port based on whether the request is HTTP or HTTPS.

nashyura
  • 85
  • 1
  • 7

1 Answers1

2

X-Forwarded-For has nothing to do with the server. It's the IP address of the client. It's appended to the request headers so that the web server can identify the real client instead of the reverse proxy. The other headers you mention were de-facto standards which have now been superceded by RFC 7239. According to the RFC, the port number would be included in the host section of the Forwarded header like this:

Forwarded: for=192.0.2.60;proto=http;host=example.com:888;by=203.0.113.43

I suspect that some reverse proxies add the port number as part of the X-Forwarded-Host header, after a colon, just like it would be in the Host header, but since it's not a defined standard header, you'll just have to try it with your reverse proxy to see.

See also: What is a full specification of X-Forwarded-Proto HTTP header?

Community
  • 1
  • 1
James
  • 3,551
  • 1
  • 28
  • 38
  • The client **is** what I'm interested in. I saw the link you cite in your response, but I'm trying to make my app work with what's out there now. I have an installation of IIS 7 with ARR 2.5, and at this time, it does not seem to be providing the `Forwarded` header by default when acting as a proxy. – nashyura Mar 20 '15 at 01:59
  • What port are you expecting, and other than recording it, what do you think you might do with it? It will be a dynamic high port, and It will be connected to IIS, so you won't be able to send anything to it. It sounds like you don't quite understand how ports work. In most cases, a server listens on a fixed port (such as 80 or 443) and a client connects to that port using a dynamic high port. The port numbers are rarely the same on both sides. – James Mar 20 '15 at 03:34
  • Expecting 80 or 443 (the server port to which the client makes the requests). Reason: my app is trying to send a url that links back to my application, and I am sending this url to a client that is on the opposite side of a reverse proxy. So a GET req to my app like `https://site/myapp.aspx` might come to my app with the url string looking like `http://svrBehindFirewall:45/myapp.aspx. If I want to send back a url that links back to my site, I will need to know what the original protocol was (https), original server name, and what the original target port was (likely 443). – nashyura Mar 20 '15 at 04:07
  • If I send back to the client a url like `http://serverBehindFirewall:95/myapp.aspx?page=2`, then the request to that URL by the client will never reach my app. – nashyura Mar 20 '15 at 04:07
  • PS. I understand quite well how ports work, since I used to drink them all the time. – nashyura Mar 20 '15 at 04:45
  • The server-side port number would logically be with the server-side hostname, not with the client-side hostname/address in `X-Forwarded-For`. This is how the new spec for the `Forwarded` header is defined. If the implementor of the code for `X-Forwarded-Host` in your reverse proxy chose to implement that header the same way as the new spec, that's where that port number would be. Many reverse proxies are programmable and allow the administrator to specify which headers get inserted with which values, in which case you may be able to do it yourself. – James Mar 20 '15 at 12:21
  • Oh my! I must have been drinking my port during this discussion. Your last comment closed the gap in my mind re: `X-Forwarded-For`. For some crazy reason, I understood the `X-Forwarded-For` header to contain the target IP of the originating request (even though you and the wiki clearly stated otherwise). – nashyura Mar 20 '15 at 15:38
  • Going to +1 your answer, and edit my question, but I'm still up the creek re: trying to figure out the original target of the request, so I'd like to keep it open. – nashyura Mar 20 '15 at 15:39
  • Actually, nm. You did answer my question. What my next step should be is probably a different post. Thank you. – nashyura Mar 20 '15 at 15:42