Multiple Reverse Proxies

[StuartFletcher1]

Hi there,

We have an ArcGIS Server 10.1 instance that sits behind 2 corporate reverse proxies (Apache). Basically in this configuration:

ArcGIS Server  ---Reverse Proxy 2----   Internal Site   ----Reverse Proxy 1----    External Site

The reverse proxies we are using utilise Apache and are configured based on the info below

Reverse Proxy 2 configuration:
ProxyPass       /arcgis/rest/  http://arcgisserver_address:6080/arcgis/rest/
ProxyPassReverse /arcgis/rest/  http:// arcgisserver_address:6080/arcgis/rest/
ProxyPass       /arcgis/tokens/  http://arcgisserver_address:6080/arcgis/tokens/
ProxyPassReverse /arcgis/tokens/  http://arcgisserver_address:6080/arcgis/tokens/
ProxyPass       /arcgis/services/  http://arcgisserver_address:6080/arcgis/services/
ProxyPassReverse /arcgis/services/  http://arcgisserver_address:6080/arcgis/services/
ProxyPass       /arcgis/sdk/  http://arcgisserver_address:6080/arcgis/services/
ProxyPassReverse /arcgis/sdk/  http://arcgisserver_address:6080/arcgis/services/


Reverse Proxy 1 configuration:
ProxyPass       /  http://internalsite_address/
ProxyPassReverse  /  http://internalsite_address/

This largely works ok however some components of the ArcGIS server REST endpoint do not function correctly as it appears that some of the java libraries used by the pages appear to pickup the fact that the request has been parsed through via a reverse proxy and utilise one of the following HTTP headers X-FORWARDED_HOST or X-FORWARDED-SERVER. This works ok when there is only 1 proxy however when there are two (or more) proxies these headers contain a comma separated list of all proxies.

I.e in the case of the above example:
X-FORWARDED-HOST = externalsite_address, internalsite_address

This causes issues with many rest pages that when returned have malformed URLs as they contain multiple comma separated domains including the javascript map preview, the wmts capabilities and the links at the top of all rest pages (to name a few).

This can be fixed partially by modifying some of the JSP files used however it is not possible with some such as the the page you are redirected to after login. Fixing the JSPs involves converting the urls to just the absolute path not a fully qualified url. This is not an ideal solution and will cause maintenance issues in the future.

The best overall solution would be for ESRI to look at changing the behavior of some of the classes used including:
com.esri.discovery.app.util.DiscoveryUrlUtil
com.esri.client.app.util.ClientUrlUtil
com.esri.rf.util.RUtil


I wouldn't have thought we are the only organisations using a chain of reverse proxies. Has any one else experienced these problems and if so how have you dealt with them.

Thanks,

Stuart Fletcher

[JoanneMcGraw]

Sander,

Thank you for your response. It's been a while since I was working on this (a month seems like forever these days) but, if I understand you properly, I tried what you are suggesting at that time and it did not work given our particular architecture. From what I remember, unset-ting the X-Forwarded-Host meant that the ArcGIS Server was creating a path something like (using your example) http://ApacheReverseProxy2/rest/services/... which is not an Apache server that the Internet has direct access to. It is forbidden. For us, the path has to be http://ApacheReverseProxy1/rest/services in that case.

When I get a moment, I will try this again to verify what I am remembering is correct ... perhaps I just made a mistake somewhere along the way before. I was trying a LOT of things at the time.

I'll let you know how it goes...
jtm

[JoanneMcGraw]

Okay, yes, I am remembering this correctly. I appreciate your taking the time to make the suggestion, Sander, and hope it can help others. In our environment, unfortunately, it doesn't solve the problem because we forbid direct access to ApacheReverseProxy2.

FYI, in the interim, we have received approval to add another RewriteRule on the organization's proxy server that directs the /rest/services traffic directly to the Web Adaptor host rather than through our application-specific host. They are not happy about it and they want it removed. However, there does not appear to be any other way around the problem with ArcGIS Server 10.1. We are waiting to see what the "fix" is that Ravi mentioned previously and to learn if it handles Apache's implementation to set values for the X-Forwarded-Host header key (when going through a proxy) rather than just IIS's.

Cheers,
jtm