Select to view content in your preferred language

REST API - View in "ArcGIS JavaScript" link not working (Reverse Proxy)

3583
7
02-07-2012 11:12 AM
DavidMarley
Frequent Contributor
We have a test/development ArcGIS Server 10 instance, configured for Internet access using a standard reverse proxy configuration (Server 2003 / IIS 6 / Apache HTTP and mod_proxy - configured per Esri guidelines).  Most of the REST API is working fine from the Internet side.  I can generate map images, consume services in Flex and Silverlight..many other things.  The things that are not working are the View in ArcGIS JavaScript and ArcGIS.com Map links from the MapServer pages.  I have updated rest.config with the appropriate external urls (SoapUrl and the others, as noted here and here) and am able to View in ArcMap using that link.

After clicking View in ArcGIS JavaScript for a service, I look at the response in Firebug and can see that the url the JavaScript API is using does not have the port (8080) appended after the dns name in the Url.  So the Javascript code in the response looks like this (note no :8080😞

var layer = new esri.layers.ArcGISDynamicMapServiceLayer("http://www.<my-domain-name>.com/ArcGIS/rest/services/<folder>/<service>/MapServer");
but should be this (note the :8080 after the domain name):

var layer = new esri.layers.ArcGISDynamicMapServiceLayer("http://www.<my-domain-name>.com:8080/ArcGIS/rest/services/<folder>/<service>/MapServer");


If I copy/paste the response HTML into a new htm page and add the :8080 myself, it works perfectly.

Also as noted above, the "View in ArcMap" link works fine externally as do most other aspects of the REST API, so the map service Urls and rest.config appear to all be configured properly.

So any ideas why the :8080 is getting dropped?  I assume this is a REST configuration issue.  Does the ReverseProxyPort tag in rest.config have anything to do with this?  I can't find any documentation on what that tag is suppose to do.  I tried changing it to 8080 but that brought my whole site down, so that (alone) clearly is not the solution.

Any help is greatly appreciated.  Thanks.

The server in question is running ArcGIS Server 10 SP 2.
0 Kudos
7 Replies
RaviNarayanan
Esri Contributor
David,

Is this ArcGIS Server for Java? Is so, the reverse proxy port needs to be configured. See this help topic for more info:
http://help.arcgis.com/en/arcgisserver/10.0/apis/rest/config.html#jports

config.reverse-proxy-http-port=8080
0 Kudos
DavidMarley
Frequent Contributor
Ravi,

Thanks for the reply.  I am using ArcGIS Server for .NET, not Java - sorry, I should have mentioned that.

It would seem to me that the ReverseProxyPort tag in rest.config would be the analagous setting for .NET.  But the .NET documentation does not even mention that tag so I cannot be sure.  And when I tried to change that value to 8080, it did not work.

Any thoughts about what to do for .NET?
0 Kudos
RaviNarayanan
Esri Contributor
The recommended solution in .NET is to set the port (not reverse proxy port ) value to the external port. Can you give this a try?
0 Kudos
danbecker
Frequent Contributor
i'm having this exact same problem; not being able to view footprints in JS api through reverse proxy.

Did you ever find the problem?
0 Kudos
DavidMarley
Frequent Contributor
I finally got a chance to check this out. Changing the value of the "Port" setting in rest.config does fix the external "ArcGIS JavaScript" link, but then the link no longer works via the internal url. Inspecting the internal url via Firebug, I can see (as expected) it is appending the 8080 port to the internal url as well, which is incorrect:

http://<myserver>:8080/arcgis/...

So apparently the JavaScript link can only work for one or the other -- internal or external -- but not both, which does not make much sense. Something's not adding up here - there is a setting "ReverseProxyPort" which does not appear to do anything, and a setting "Port" which affects both the internal and reverse proxy port. Seems like there's an issue inside ArcGIS Server here -- the .NET version anyway.  From Ravi's comments above it seems that this does work for Java deployments.

So it appears, at least for now, that I will have to live with the external (or the internal) link not working.

BTW, the server in question is now upgraded to Service Pack 4 - but that has not made a difference.

Dave
0 Kudos
DominicDoiron
Occasional Contributor
Hi,

As a solution for this ever been found?

Thank you,

Dominic
0 Kudos
DavidMarley
Frequent Contributor
No I never found anything beyond the information in my previous post - which is basically that you can either have it work internally or externally, but not both. It appears to only use the "Port" value and ignores the "ReverseProxyPort" setting - to me this sounds like a bug where somewhere under the hood AGS uses Port somewhere where it should be using ReverseProxyPort.

Note that at this point Service Pack 5 is out - and I have not applied that to see if it fixes the issue.  I don't see anything like this listed under the issues addressed with SP5, so my guess would be that it's not fixed still:

http://gisupdates.esri.com/10sp5/ArcGIS/ArcGIS10sp5-issues.htm#Rest-sp5
0 Kudos