Export Web Map Task Error: 'unable to connect to map server' only at the first time

[SimonLeo]

Hi all,

I am developing a web app based on ArcGIS JS API. one simple task is to export map to image. I am using Esri Basemaps. It behaves strangely that always pops up exception at the first time you execute Export_web_map task, then it will work fine in following times. Here, 'the first time' means right after this application is loaded.

The error details:
"Error executing tool.: Layer "layer0": Unable to connect to map server at http://services.arcgisonline.com/ArcGIS/rest/services/World_Topo_Map/MapServer. Failed to execute (Export Web Map). Failed to execute (Export Web Map Task)."

This case is very similar to one previous post at this forum: Export Web Map Task Error: "Unable to connect to map server...". But that case happens every time user execute export_map task, while in my case it only happens at the first time.

I also have a proxy on web server since this app requires feature_editing functions. part of proxy.config:

<serverUrl url="http://services.arcgisonline.com/ArcGIS/rest/services/" 
               matchAll="true"></serverUrl>
    <serverUrl url="http://sampleserver1.arcgisonline.com/arcgis/rest/services/" 
               matchAll="true"></serverUrl>
    <serverUrl url="http://sampleserver2.arcgisonline.com/arcgis/rest/services/" 
               matchAll="true" 
               token=""></serverUrl>
    <serverUrl url="http://server.arcgisonline.com/arcgis/rest/services/"
               matchAll="true"></serverUrl>
    <serverUrl url="http://orthogonal.esri.com/arcgis/rest/services/"
               matchAll="true"></serverUrl>

I added http://services.arcgisonline.com/ArcGIS/rest/services/ in it, but it still does the same thing.

the proxy is .NET based on IIS7.5

any suggestions will be appreciated!

[JohnGravois]

What happens when you fire the request directly at the REST endpoint?

ie....
http://sampleserver6.arcgisonline.com/arcgis/rest/services/Utilities/PrintingTools/GPServer/Export W...

is your application actually using a proxy to make the print request?

[SimonLeo]

thanks for your reply!

using 'Execute Task' web page is fine from my few tries. but note that the problem with my web app map_export only happens at the first time after the app is initially loaded into browser. one interesting thing is, if I tested it on chrome, then load it again on FF, then even if it's loaded into FF as first time, the map_export still functions well. I am wondering whether it's related to starting the printing_service on server. but I set the service running all the time...

on proxy, this is something I am not sure whether it's related. This map_export problem happened before I set up a proxy. The reason why I need a proxy is to have feature_editing functions. the problem is there with or without proxy.

here is something on proxy setup:
In initial proxy configs, there is no 'http://services.arcgisonline.com/ArcGIS/rest/services'. so I added following item:

<serverUrl url="http://services.arcgisonline.com/ArcGIS/rest/services/"  
matchAll="true"></serverUrl>

however, when the app is loaded, it still reports:

XMLHttpRequest cannot load   http://services.arcgisonline.com/ArcGIS/rest/info?f=json. Origin   http://localhost is not allowed by Access-Control-Allow-Origin.

is this normal? or something related to the map_export problem? the problem details:

"Error executing tool.: Layer "layer0": Unable to connect to map server at   http://services.arcgisonline.com/Arc..._Map/MapServer. Failed to execute (Export Web Map). Failed to execute (Export Web Map Task)."

What happens when you fire the request directly at the REST endpoint? 

ie.... 
http://sampleserver6.arcgisonline.com/arcgis/rest/services/Utilities/PrintingTools/GPServer/Export W...

is your application actually using a proxy to make the print request?

[BrettGreenfield__DNR_]

Are you certain your proxy is working correctly?  I had a similar issue when trying to create a print task to a web map; the first time I clicked the Print button I would get an error, but it would work if I clicked it a second time.  It turned out my proxy wasn't set up properly; correcting that fixed the problem.

[SimonLeo]

this seems exactly what i am having now.

but how to double check whether my proxy is working properly or not? as far as i know, the feature_editing functions run well which means the proxy should be fine.

do you have any recollections on what problem your proxy had? and how to fix it?

But again, this problem happened before even the proxy is used. Does printing basemaps from 'services.arcgisonline.com' requires a proxy?

thanks!

Are you certain your proxy is working correctly?  I had a similar issue when trying to create a print task to a web map; the first time I clicked the Print button I would get an error, but it would work if I clicked it a second time.  It turned out my proxy wasn't set up properly; correcting that fixed the problem.

[BrettGreenfield__DNR_]

I believe my error was due to downloading the proxy from an older help page (which had an older version of the proxy).  Once I found the newest version of the proxy and had it set up, it fixed my problem.

I just spent a few minutes looking through the new JS API Resources page trying to find the newest version of the proxy for you, but I can't seem to track it down.  ESRI really needs to work on getting a search function up and running again!

[SimonLeo]

the page is here:
http://help.arcgis.com/en/webapi/javascript/arcgis/jshelp/#ags_proxy

I think I did use the latest version. but let me double check...

I believe my error was due to downloading the proxy from an older help page (which had an older version of the proxy).  Once I found the newest version of the proxy and had it set up, it fixed my problem.

I just spent a few minutes looking through the new JS API Resources page trying to find the newest version of the proxy for you, but I can't seem to track it down.  ESRI really needs to work on getting a search function up and running again!

[JianHuang]

Simon,

Are you using your own print service hosted on your domains? or, you just use the one on sampleserver6 from arcgisonline.com?

Here I'm trying to explain the detailed information about use cases of proxy page. Hopefully this will clear up all proxy page related mysteries. The sample link for item 6 is on my local machine, so that I couldn't share it. But feel free to ask any questions.

The general rule regarding when proxy page is required is this: when cross domain requests are required, always configure a proxy page for the application. The ArcGIS API for JavaScript is smart enough to determine when to use it.

The same origin policy is a security concept, which restricts requests made by an application to the host domain of the application. For example, if the web application is hosted on www.xyz.com, when there is any request to any domain that is not xyz.com, it is not allowed. There are exceptions to this policy: CSS, images and JavaScript loaded through link, img and script tags, respectively, are allowed to make cross domain requests. For more detailed info, refer to the following: same origin policy on Wikipedia (http://en.wikipedia.org/wiki/Same_origin_policy) same origin policy on the Mozilla Developer Network(MDN) (https://developer.mozilla.org/en-US/docs/JavaScript/Same_origin_policy_for_JavaScript?redirectlocale...).

Below is a detailed list of common scenarios that require cross domain requests. In each case, an explanation is provided describing whether or not a proxy page will be used. In all cases, a proxy should be set up so that an application can use it if necessary.

1. If the services support CORS, (all 10.1 ArcGIS Server service should support CORS), and at the same time, if the browsers support CORS as well, it doesn�??t need proxy. Here is an example. http://help.arcgis.com/en/webapi/javascript/arcgis/samples/widget_print/index.html
If using Firefox or Chrome, this application sends the print request without using the proxy page.
But IEs don�??t support CORS fully, as application developers, it�??s always safe to put proxy page to satisfy all browsers.

2. Even without CORS support, for instances, ArcGIS Server 10 services don�??t support CORS, since the services support JSONP, only when the request is through POST, it needs proxy page.
   a. The request is through GET, proxy is not necessary. An example
http://help.arcgis.com/en/webapi/javascript/arcgis/samples/query_nomap/index.html

By examing the request, the query is going through an HTTP GET through a URL, you can see the response has a jsonpCallback attached to the returned json, which eliminates the usage of proxy page.
   b. The request is through POST, because the request is large enough to exceed 2000 characters. For example:
http://help.arcgis.com/en/webapi/javascript/arcgis/samples/query_gpresult/index.html

   c. The request is through POST, because the request is required to be POST by server, such as editing cases where POST is mandatory.
http://help.arcgis.com/en/webapi/javascript/arcgis/samples/ed_default_editingwidget/index.html

For case 2.b and 2.c, the response doesn�??t have the callback parameter attached ahead of the json.

In short, when JSONP + GET, proxy page is not needed. When JSONP + POST, proxy page is necessary.

3. If the response is other formats than JSONP, proxy page is always needed. An example is when loading WMTS layer, the first request is to get the capabilities XML, since the format is not JSONP, it always has to go through a proxy page to get the XML.
http://help.arcgis.com/en/webapi/javascript/arcgis/samples/layers_wmtslayer/index.html
You can see that the capabilities XML is got through a proxy page. (even though the sample doesn't work at this moment due to the service is down, you can still see the request through proxy).

4. When uploading files, some browsers (of course, IE) don�??t support the native uploading method, so it is always required to have a proxy page in between so that iframe can do the job of uploading.
http://help.arcgis.com/en/webapi/javascript/arcgis/samples/ed_attachments/index.html

5. When generating a token through a token service, since neither ArcGIS Server 10 nor ArcGIS Server 10.1 token service support CORS, proxy page is always needed. An example is when use identity manager.

6. It is possible to force to use proxy page all the time by setting esri.config.defaults.io.alwaysUseProxy = true. For some cases, the services may be behind fire wall or other security settings, proxy is always necessary.
http://localhost/localjsapi/test/alwaysproxy.html
You can see all the requests to get the image tiles are through a proxy page.

All of the above use cases are under the assumption that there are cross domain requests. If all the requests are to the same domain as the application, it never needs proxy page. Even putting a proxy page there, it won�??t use it. For example:
https://servicesbeta.esri.com/demos/widget/widget_identitymanager.html
The app is the same domain as the token service, so it ignores the proxy page setting and get the token directly.

[JianHuang]

Simon,

For you case, it's item 1 on the list in my previous post. You were seeing the msg in console: XMLHttpRequest cannot load http://services.arcgisonline.com/Arc...st/info?f=json. Origin http://localhost is not allowed by Access-Control-Allow-Origin. Esri JS API always sends a tentative request to test if the service supports CORS. This msg tells that you have cross domain requests, and the tests for CORS finished. Later on, when more requests for this domain, it will decided whether use proxy page or not.
If your print service is not under arcgisonline.com, then before you click the print button, JS API doesn't have an opportunity to test CORS support. When clicking print, it will send the test request, but the print request doesn't wait for the result of the test. That's why the first time it will go through proxy page. And if the proxy page happens to have some problems, the first request will fail. But the next time, JS API already finished the test for CORS, it won't use proxy page any more and the request will be through successfully.
Sometimes, if the test call finished soon enough before the print request, even the first time, it won't need proxy page.
Anyway, as I said for item 1 in the list, always put a proxy page there for this case if CORS may be supported. So that you will not run into the issue that print service is under some domains that have not been tested.
So the issue on your case is on your proxy page. As Brett pointed out that he fixed the issue just by fixing the proxy page.

[JianHuang]

One more thing, this is not just for print service. It happens for any types of service, for example geometry service. If you are trying to reproject a geometry through a geometry service, and the domain of the geometry service has not been accessed before, the same situation will happen. It will send a call to rest info to decide if CORS is supported or not, but the first request to the geometry service will go through proxy since it doesn't know the result yet from the rest info call.