Hello,
I have a public-facing Win Server 2008 R2 web server that resides on an internal network and is accessible by the public via a proxy server. ArcGIS for Server 10.3 is installed on the server.
A WAB app developed with WAB Dev 1.1 is hosted on the server. It contains the Query widget for which I have configured a query to a locally-hosted service of a tiled geodatabase. In config_Query.json for the widget, when the url of the service being queried is set to an internal address, i.e.
{
"queries": [
{
"name": "Select geologic unit attributes from SGMC Geology layer",
"url": "http://internal/arcgis/rest/services/usminmap/SGMC_March2014_Geology/MapServer/1",
all queries function normally if executed from a computer on the internal network. Such queries obviously won't work for the public.
Here are data from the Windows server log for a successful query:
2015-04-14 16:01:07 INTERNAL_IP GET /arcgis/rest/services/usminmap/SGMC_March2014_Geology/MapServer/1/query f=json&returnIdsOnly=true&where=(Generalized_Lithology%20%3D%20%27Sedimentary%2C%20carbonate%27)%20AND%20(UPPER(Age_Min)%20LIKE%20UPPER(%27%25paleozoic%25%27)%20OR%20UPPER(Age_Max)%20LIKE%20UPPER(%27%25Tertiary%25%27))&returnGeometry=false&spatialRel=esriSpatialRelIntersects&geometry=%7B%22xmin%22%3A-12907141.088345297%2C%22ymin%22%3A4789348.7478497615%2C%22xmax%22%3A-12687461.069053616%2C%22ymax%22%3A4951089.499701257%2C%22spatialReference%22%3A%7B%22wkid%22%3A102100%7D%7D&geometryType=esriGeometryEnvelope&inSR=102100&outSR=102100 80 - INTERNALcomputer.cr.usgs.gov Mozilla/5.0+(Windows+NT+6.1;+WOW64;+rv:37.0)+Gecko/20100101+Firefox/37.0 200 0 0 53
2015-04-14 16:01:07 INTERNAL_IP POST /arcgis/rest/services/usminmap/SGMC_March2014_Geology/MapServer/1/query - 80 - INTERNALcomputer.cr.usgs.gov Mozilla/5.0+(Windows+NT+6.1;+WOW64;+rv:37.0)+Gecko/20100101+Firefox/37.0 200 0 0 209
2015-04-14 16:01:09 INTERNAL_IP GET /arcgis/rest/services/usminmap/SGMC_March2014_Geology/MapServer/tile/9/194/89 - 80 - PROXY.cr.usgs.gov Mozilla/5.0+(Windows+NT+6.1;+WOW64;+rv:37.0)+Gecko/20100101+Firefox/37.0 200 0 0 4
2015-04-14 16:01:09 INTERNAL_IP GET /arcgis/rest/services/usminmap/SGMC_March2014_Geology/MapServer/tile/9/191/89 - 80 - PROXY.cr.usgs.gov Mozilla/5.0+(Windows+NT+6.1;+WOW64;+rv:37.0)+Gecko/20100101+Firefox/37.0 200 0 0 5
...
If the service url in the query widget json config is changed to the public address,
{
"queries": [
{
"name": "Select geologic unit attributes from SGMC Geology layer",
"url": "http://public/arcgis/rest/services/usminmap/SGMC_March2014_Geology/MapServer/1",
then most, but not all, queries executed from a computer outside the internal domain fail. Here are data from the Windows server log for a failed query:
2015-04-14 15:56:08 INTERNAL_IP GET /arcgis/rest/services/usminmap/SGMC_March2014_Geology/MapServer/1/query f=json&returnIdsOnly=true&where=(Generalized_Lithology%20%3D%20%27Sedimentary%2C%20carbonate%27)%20AND%20(UPPER(Age_Min)%20LIKE%20UPPER(%27%25paleozoic%25%27)%20OR%20UPPER(Age_Max)%20LIKE%20UPPER(%27%25Tertiary%25%27))&returnGeometry=false&spatialRel=esriSpatialRelIntersects&geometry=%7B%22xmin%22%3A-12940874.99811248%2C%22ymin%22%3A4735422.92926457%2C%22xmax%22%3A-12721194.978820799%2C%22ymax%22%3A4897163.681116065%2C%22spatialReference%22%3A%7B%22wkid%22%3A102100%7D%7D&geometryType=esriGeometryEnvelope&inSR=102100&outSR=102100 80 - PROXY.cr.usgs.gov Mozilla/5.0+(Windows+NT+6.1;+WOW64;+rv:37.0)+Gecko/20100101+Firefox/37.0 200 0 0 78
(There is no return POST request).
No errors or warnings are recorded in ArcGIS for Server logs. I've asked our IT person, and he has no clue about this.
How can I get the queries by the public to execute normally? 
The public WAB app behaves normally otherwise, including REST requests from a custom Identify widget to the same service.
Thank you in advance...
Accepted Solutions
It turns out our security people who manage the proxy server had a mistake in blocked directory locations on the public server. 
Once they fixed it, queries of the service via the public url executed from internal and public computers complete normally. 
It turns out our security people who manage the proxy server had a mistake in blocked directory locations on the public server.
Once they fixed it, queries of the service via the public url executed from internal and public computers complete normally.
