Proxy page use cases

[JianHuang]

Over the years, there were quite many questions regarding the proxy page. 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 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/...for_JavaScript).

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://developers.arcgis.com/en/javascript/samples/widget_print/
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://developers.arcgis.com/en/javascript/samples/query_nomap/

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://developers.arcgis.com/en/javascript/samples/query_buffer/
This is a perfect example. You can see there are two requests. The first one is a call to a GP service to perform a buffer calculation, which is through GET, so that it doesn't use proxy. While the second request to query features within the bufferred area, it needs to include the geometry of the buffer in the request, which is too big to use GET, so that a POST is sent through proxy.

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://developers.arcgis.com/en/javascript/samples/ed_simpletoolbar/

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://developers.arcgis.com/en/javascript/samples/layers_wmtslayer/
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://developers.arcgis.com/en/javascript/samples/ed_attachments/

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.

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/...tymanager.html
The app is the same domain as the token service, so it ignores the proxy page setting and get the token directly.

[ErwinSoekianto]

Resource Proxy‌ well-explained use case of proxy page

[Anonymous User]

so, off the wall question, but, can I use the ESRI proxy for my Screenshot widget for WebApp Builder?

Kevin's Custom WAB Widgets

see #3, Screenshot.

Click Screenshot, see the issue? It doesn't load the ESRI data, the map layers and basemap png image tiles. Not for this site or arcgis.com itself when tested using Niklas' test page. This is all based on html2canvas: niklasvh (Niklas von Hertzen) · GitHub    I am trying to use either ESRI proxy or this proxy brcontainer/html2canvas-php-proxy · GitHub  .. javascript - How to use html2canvas proxy - Stack Overflow    no luck yet on either.  Is the ESRI proxy really just to be used for ESRI AGS services? I see mostly things relevant to ArcGIS Server when I opened up the Esri proxy.php file, like handling json, logging in with AGS tokens etc.

Since they are images anyway I'm confused why CORS should even be an issue. I was thinking this would just 'work'. Note that this html2canvas library is very nicely coded and provides detailed console logging which I enabled. Any thoughts for folks very experienced in all the mysteries of proxies? I thought this would be a relevant page to bring up.