myESRIUName

"View In:ArcGIS JavaScript" in HTML fails when routing through multiple proxy servers

Discussion created by myESRIUName on Jun 7, 2013
Latest reply on Jun 13, 2013 by myESRIUName
Hello all,

In our organization, all web pages and applications must be routed through a proxy server (for the purposes of this thread, I'll call it "our_ps"). We have no choice in this.

To access anything related to our organization's web mapping applications, the first path component in a URL to our_ps must be "arcgis". So, a URL like "http://our_ps.net/arcgis" will transfer its request to another web mapping proxy server (which I'll call wm_ps) where there are a number of reverse proxies, aliases and rewriterules defined, all related to our organization's web mapping applications only.

On wm_ps we direct URLs whose first path component is "arcgis" to a Web Adapter that load balances between 2 ArcGIS Servers.


So, a call like "http://our_ps.net/arcgis/rest/services" would:
1. Go through our_ps.net/arcgis to wm_ps/arcgis;
2. wm_ps/arcgis would be further transferred to the Web Adaptor; and,
3. the Web Adaptor would transfer the request to one of 2 ArcGIS Servers.

Given this setup, after navigating to a mapping service through the ArcGIS Server's rest/services pages, if you try to "View In: ArcGIS JavaScript" the map will not be populated because the URL generated for the layer instantiation is invalid. It looks like this (note the comma-separated "domain:port" section of the URL):

var layer = new esri.layers.ArcGISDynamicMapServiceLayer("http://our_ps.net, wm_ps.net/arcgis/rest/services/...");


We are working with ArcGIS Server 10.1 on Linux. We tried it in 10.0, but it fails even worse there; we also tried, in 10.1, redirecting through 3 servers and found that the URL in the HTML simply included all three with a comma separating them as above. So, I think it's safe to say that as many servers as you have to route through to get to the ArcGIS Server with the mapping service in question will all be included in the URL.


Further, I have copied the generated HTML source, saved it to a local file, edited the URL for the layer instantiation to say what I expect it to (that is, http://our_ps.net/arcgis/rest/services/...) and the page then works fine.


So, I guess my questions are: why/how is ArcGIS Server generating that URL it is inserting in the HTML page and is there a configuration or something somewhere that we need to set to get this type of thing to work. We tried setting the WebContextURL to "http://our_ps.net/arcgis" on the two ArcGIS Servers but it didn't make any difference. We restarted each after making that change.


If you'd like to set up a small test to see this, I can tell you how using 2 seperate Apache servers that are accessible by the Internet. One will act as our_ps.net and the other as wm_ps.net which will point to the ArcGIS Servers found at http://servicesbeta2.esri.com/arcgis (I'm assuming there's a Web Adaptor there to load balance across a number of ArcGIS Servers and it's not just a single ArcGIS Server).

1. In the Apache config file on the host that will act as wm_ps.net, add the following directives:
LoadModule rewrite_module modules/mod_rewrite.so
RewriteEngine on
RewriteRule ^/arcgis(.*)$ http://servicesbeta2.esri.com/arcgis$1 [P,L,QSA]


2. In the Apache config file on the host that will act as our_ps.net, add the following directives:
LoadModule rewrite_module modules/mod_rewrite.so
RewriteEngine on
RewriteRule ^/arcgis(.*)$ http://wm_ps.net/arcgis$1 [P,L,QSA]


3. In a Web Browser, go to "http://our_ps.net/arcgis/rest/services" and ensure it looks the same as when you go to "http://servicesbeta2.esri.com/arcgis/rest/services"

4. Click on the "USA (MapServer)" link.

5. In the resulting page, click on the "ArcGIS JavaScript" link to view the service in a map.

6. In the resulting page, where I would expect to see a map, I don't because the URL in the HTML is invalid, as described above.


Can anyone comment on this? We are trying to move our applications into our production environment for release this week but have found this problem to be insurmountable so far and, consequently, our applications are unreleasable. I have opened a ticket with ESRI support here in Canada but, as this is kind of critical for us at the moment, I thought I'd put it in the forums in case someone can suggest something quickly.

Cheers,
jtm

Outcomes