Geocode Addresses service fails after 10 addresses with "404 - File or directory not found" Error

1860
1
02-22-2016 09:31 AM
KDeVogelaere
Occasional Contributor

A solution for "404 - File or directory not found" when using GeocodeAddresses in ArcGIS Server 10.3.1 was shared with me by a member of the ESRI staff, Dennis Jarrard, I've re-posted the solution on his behalf.

Environment:  Windows Server 2008 R2;  IIS 7.0;  ArcGIS Server 10.3.1

Problem:  We have published our address locator file to ArcGIS Server and attempted passing-in addresses to the Geocode Addresses REST endpoint (http://<ServerName>/arcgis/rest/services/<LocatorName>/GeocodeServer/geocodeAddresses?addresses={"records": [.....) for geocoding.  We are successful geocoding up to about 10 addresses, but have not been able to geocode a larger amount of addresses.

Solution: 

The issue here may be a length limit. Typically length limits are applied through all proxies and endpoints. Even modern browsers can sometimes limit URL length. ArcGIS Server has a length limit, though I do believe it’s a bit longer than what you’ve shared. My guess is that the web adaptor may be imposing a limit (as it works under the constraints of IIS). To test this, you could try sending the request directly to ArcGIS Server (port 6080) instead of through the web adaptor. However, that’s not really a permanent fix.

When sending large amounts of data through a request, or if you need to conceal the parameters of the request, you should use a POST request. In the example you’ve provided, it appears to be a GET request. The difference is that in a GET request, all parameters and values are specified in the URL. This means that the URL can get quite long and unruly. For most query or Find Address Candidates requests, which are short and simple, this is usually just fine. When you start passing many addresses with several fields, you run into length issues. A POST request transmits all of the parameters and values in the body of the request instead of using the URL. Not only does this mean that you can clean up the URL, but it also means that the parameters themselves are not visible to prying eyes. If you send a post request over HTTPS, the body itself is completely encrypted. I’m not sure whether this is important to you, but it’s something to consider.

To send a POST request instead of GET, you can start at the REST endpoint of the service. Go to this endpoint in your browser and fill out the parameters with the information. When ready, click POST instead of GET. If you get different results depending on which one you click, then we likely have our answer. If you’re sending these requests through an application, you’ll need to slightly modify your app so that the request is sent using POST instead.

-K

0 Kudos
1 Reply
JonathanQuinn
Esri Frequent Contributor

It's interesting that the request wasn't met with an error that the request length was too long, which is what I thought you'd typically see if the GET request length was actually too long.  I took a further look and it seems like a GET request length of 1339 characters returns a 404, but a length of 1237 returns a successful response.  It wasn't until I got to a length of 7867 characters that i got the Bad Request - Request Too Long error instead of a 404.  Either way, the 404 response is misleading and we can look into that a bit more.