Using the REST endpoint on a feature service, it appears that all attachments are returned with a context type of "text/plain" rather than what is displayed for the attachment. In my case, I have a pdf which has a content type of application/pdf, but when I click the link to view/download it (from the .../FeatureServer/0/1234/attachments page), it just dumps the encoded file as a text stream.

Does anyone know how to make this work properly? My only thought it to just write up a custom servlet to return the file with the correct content type set, but this seems like something that should work properly through the REST endpoint, particularly since ESRI goes to the trouble of saving the actual content type in the attachments table.

  • All you're doing is clicking from the services directory? Both jpg and pdf work fine from SS6 which is Server 10.3: sampleserver6.arcgisonline.com/arcgis/rest/services/SF311/… – KHibma Mar 18 '16 at 19:18
  • Unfortunately the link you included doesn't have an attachment right now. From what I can tell, the REST endpoint doesn't allow you to search the attachments either, so finding one that does is a frustrating exercise. (I clicked through ten or so after searching for objectids where 1=1, and none had any attachments.) – Tom Mar 21 '16 at 12:55
  • They must have cleaned it up (they do that regularly). I know that search pain. You can add your own attachments to that service from the same end point. Just pick a feature and attach whatever for your test. – KHibma Mar 21 '16 at 12:57
  • Because I'm particularly slow on Monday mornings, it only just now occurred to me to add my own test pdf to a point in that table, and sure enough, it returns with the correct content type. The URL of my test record is here: link, and I have no idea why our own ArcServer isn't behaving the same way. (it's also version 10.3) – Tom Mar 21 '16 at 13:03
  • Then I'd look at your particular server, and I'm guessing you have a web adapter with something like IIS or apache or other? The issue might be in there. – KHibma Mar 21 '16 at 13:05

PDF does not appear to be a supported type for ArcGIS to retrieve:

esriRequest is a utility method to retrieve data from a web server. Data can be static (stored in a file on the web server), or it can be dynamic (generated on-demand by a web service). esriRequest can handle the following formats:

plain text




"JSON with padding"

In the case that you just threw out PDF as an example, I have expanded for other types below:

Are you just retrieving data or creating the data? I probably should have clarified before I wrote out this answer. For data retrieval, make sure that you have the options available that are in the link below (it is entirely possible that the only option enabled is text), if you are creating, make sure that you are creating different data types and not just writing to a text file.

See this ArcGIS help link on retrieving data from a web server

Before a request can be made, some information is required:

  1. Location of the data i.e., URL
  2. For web services, any required parameters and appropriate values 3.Data format

Once these are known, there are two requirements to use esriRequest.

  1. Import the module that has the source code for the function:

require(["esri/request", ... ], function(esriRequest, ... ) { ... });

  1. If needed specify the location of the proxy. A proxy is a simple script that runs on a web server. It is automatically used by esriRequest for certain types of requests. More information is available on the proxy set up page.

A plain text request will look something like this:

var earthquakes = esriRequest({
  url: "http://earthquake.usgs.gov/earthquakes/catalogs/eqs1day-M1.txt",
  handleAs: "text"
earthquakes.then(requestSucceeded, requestFailed);

while a JSON request, for example, may look something like this:

var earthquakes = esriRequest({
  url: "http://earthquake.usgs.gov/earthquakes/feed/geojson/4.5/week",
  handleAs: "json"
earthquakes.then(requestSucceeded, requestFailed);
| improve this answer | |

Turns out this is an actual bug: http://support.esri.com/en/bugs/nimbus/QlVHLTAwMDA5MDE3MQ==

It will be fixed in 10.4.1 and 10.5, but apparently there is also a hotfix available for it (which is probably why the sample server didn't have the same issue).

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.