Child Item

Error -1017 "cannot parse response"

dethier1958

I am getting an error code -1017 "cannot parse request" from my app when it tries to download a file from Dropbox. This code has not changed for a while and has worked without trouble. I use the same code in my web app, again, without any problems. I am using the REST API in each case. Nothing fancy, pretty much exactly the same as the example in your API documents.

This happens in the XCode simulator (for iOS 15.4 or 15.0) running on an M1 Mac running Mac OS 12.3.1, but it also happens when I install and run my app on my iPhone running iOS 15.4.1 ... So first, what exactly does this error code mean? What exactly is it that cannot be parsed? Is there a problem with the http request I'm sending? I also wonder whether spaces in the file path I'm requesting could be a problem. Should those be escaped to %20 in the request?

The error is somewhat intermittent. It seems to mostly happen when opening one particular file, but it does not always happen with that file. And if I open another file successfully, then I can open the first one with no error. And I can open that same file from my web app (using the same code) without ever getting an error.

I am installing a version of the simulator running iOS 14.5 and I will experiment with that to see if the error happens with iOS 14.5. I also wonder if this is an iOS bug in their http request functions. But if that were the case, a lot of people would be running into this. So that seems very unlikely.

When I run the version of my app that is currently in the App Store, it does not have any errors opening files from Dropbox. But that version of the app was built almost a year ago.

Any help would be much appreciated!

Daniel Ethier

Find more posts tagged with

API

Abuse

Comments

dethier1958

I finished installing the XCode simulator for iOS 14.5 ... I did get the same error once, so it is not unique to iOS 15.

dethier1958

It seems that the -1017 error is coming from iOS. There is an error code, kCFURLErrorCannotParseResponse = -1017, in the SDK. So I will take a look at how I'm doing things and see if I can figure it out.

One question: What should the content-type be for the download request? There is nothing in the API example. I'm wondering if leaving that out may be causing iOS to guess wrong and choke on the request, throwing that error.

dethier1958

I suspect the issue may be that iOS does not like a POST request that does not send any data. The Dropbox /download command is supposed to be POST, but there is no body. The only thing I've done that works consistently is to do a GET instead of a POST. Dropbox still sends the data, and iOS is happy too.

Will I run into any problems if I continue using GET instead of POST with the /download command?

Greg-DB

Thanks for the report! We'll look into it, but we could use a few more pieces of information:

Can you confirm that you are not using an official Dropbox SDK (such as the official Dropbox Objective-C or Swift SDK)? In that case, what network client are you using?
Can you share the relevant code snippet(s) for reproducing this issue? (Please make sure to redact any access/refresh token.)
Can you share the full error/output you're getting?

In any case, it sounds like you're referring to the /2/files/download endpoint in particular. That endpoint officially supports both GET and POST requests, so either should be fine. (And continuing to use GET for now is fine, but POST is the standard method for it.) Requests to /2/files/download don't have a request body (since the options are sent in the "Dropbox-API-Arg" request header), and so there's no "Content-Type" request header expected, as there's no request body content to describe.

dethier1958

I'm pretty sure this is a problem with Apple's iOS SDK and how they handle POST requests with no content. I think the error was triggered before anything was even sent to your servers. I am planning on further playing with this to see if I can narrow things down more. I may continue using GET for now since that has worked perfectly for me.

If I did a POST and sent some dummy content (to make iOS happy) would Dropbox simply ignore it, since it was not expected? I may try sending an empty JSON or some dummy JSON and see if that works.

Please do notify developers though if you will no longer support GET for the download endpoint. I'd prefer to have a little warning to try to find a solution if needed.

Greg-DB

Thanks for following up. Please do let us know if you find anything else.

Unfortunately since that endpoint does not expect anything in the request body, I believe attempting to send any such dummy data would cause the call to fail validation.

And yes, in any case that we need to intentionally make a breaking change, such as hypothetically ending support GET on these types of requests, we would send advanced notice by email.