Hi All,
I've got an odd issue that I can easily reproduce in a specific environment. It's slightly complicated to explain ...
Short version: JavaScript API requests to a map service (legend, query and export) fail after the first successful attempt. The response is a 504. Using fiddler to trace these request, I've narrowed it down to the IF-NONE-MATCH header in the request. Using fiddler, I reproduce the failures, then remove this header value and the requests will process successfully. It appears to me that some interaction between the proxy, firewalls, arcgis server, etc are having a mis-communication for these request that would probably result in a 304 type response.
I don't control the network, firewall environment so I might be missing some details but this is my view of the setup:
INTERNET
|
V
PUBLIC FIREWALL
|
V
LOAD BALANCER
|
V
DMZ WEB SERVER (x2 i think)
* web app/site + proxy
* arcgis web adapter site
|
V
INTERNAL FIREWALL
|
V
ARCGIS SERVER (v10.5)
* secure map service
Here's the sequence of events I've traced so far and can reliably and consistently reproduce:
1. Start with a cleared browser cache or in-private browser window
2. Load web app/site in browser..
* all the web site resources (html, css, js etc) load correctly
* AGS REST API requests kick off and are successful:
* https://{mywebserver/site}/proxy.ashx?https://{myarcgiswebadpater/service}/MapServer/3/query?f=json.....
* https://{mywebserver/site}/proxy.ashx?https://{myarcgiswebadpater/service}/MapServer/export?f=image.....
* https://{mywebserver/site}/proxy.ashx?https://{myarcgiswebadpater/service}/MapServer/legend?f=json...
NOTE: none of these requests have an IF-NONE-MATCH header in the request and all have a ETAG header with a specific value in the response
3. Refresh the web app using the default browser button
* all the web site resources (html, css, js etc) load correctly
* AGS REST API requests kick off and all FAIL - status 504
NOTE: in each request there is now a IF-NONE-MATCH header in the request with a value that corresponds to the ETAG from the equivalent request in step #2. When I trap these requests in Fiddler and remove the IF-NONE-MATCH header, they'll execute successfully.
A few more details:
* Step #3 will continue to fail until a full browser cache clear or new in-private window...obvisouly since the caching is reset. It does appear to reset after some minutes interval but I haven't narrowed down the time window.
* When I run the website from my local dev machine or test server (web app and proxy) directed to the live map service, the refreshes will correctly load, the request headers are identical and the responses have 304 status codes.
This seems like normal browser/internet caching stuff and it works correctly from an outside web server so I'm guessing something in the hosting environment isn't configured correctly to rematch these caching requests?
Anyone have suggestions on what settings or tweaks I can pass along to the network ops staff that might remedy the current situation?
Thanks!!!
