Using resulting 'link' from get_temporary_link in IE new window shows about:blank

[KennelLink]

I'm trying to show a file (like .jpg or .pdf) in a new window of the browser.

I'm using Internet Explorer 11 on Windows 7.

I invoke get_temporary_link and use the resulting link as such:

  window.open(tempLinkResults.link)

The new window first navigates to the dropbox URL (such as https://dl.dropboxusercontent.com/apitl/1/AACt...) but then shows about:blank.  This happens for all of the jpg & PDF files I've tried.

Am I doing something fundamentally wrong?

Any ideas?

[Greg-DB]

Thanks for the report! This is a known issue with how IE handles these links. The expected behavior is that the browser would download the file, based on the Content-Disposition header. IE doesn't seem to do so, and instead does nothing, as you mentioned.

I'll send this along to the team, but I can't say if or when we'd be able to change this, as it's related to how the browser itself is handling this, which is out of our control. (Firefox, for example, downloads the file as expected.)

[Dave Q.1]

Any update? The link obtained from the API v1 works fine (using /media) but not under the API v2 (/get_temporary_link)... we're forced to update to v2 prior June but that's a real problem under IE! Thx

[Greg-DB]

No update on this unfortunately.

[akreiss]

Is there any further update on this?  I'm experiencing the same (or a similar) issue across IE, Chrome, and Firefox.  I create a temporary URL that links to something viewable in the browser like a jpg or mp3 file.  I copy that into the URL bar and the browser always just downloads the file.

Also, assuming this is fixed, will there be a way to force downloads?  The old v1 API /media endpoint allowed putting "?dl=1" on the end of the URL to force it to download.

[KennelLink]

I'm hoping there's a fix for this, but in the mean time I do the following:

1. Invoke sharing/create_shared_link_with_settings() which of course fails if the file has already been shared
2. Invoke sharing/list_shared_links() and (I personally) use the url from the first element in the list of links
3. Since the resulting URL points to the Dropbox preview page with the target file in a frame, I replace "dl=0" with "raw=1" to FINALLY get a usable URL for the file

I hope the Dropbox team realizes this is a huge endeavor just to get a temporary usable in-browser view of a file - like we used to be able to do with API v1 and it ends up poluting the shares list because I only need it temporarily and non-business accounts can't use the expiry parameter on the creating the link.

Also, some documentation of the query string arguments would be nice.  I just stumbled upon the idea of changing dl=0 to raw=1 in another thread.  I suspect that setting dl=1 would achieve the forced download you desire.

[Greg-DB]

@akreiss It sounds like you're asking for something slightly different. This thread was about an issue specific to Internet Explorer. Aside from that issue, the expected behavior is for the browser to download the file (based on the Content-Disposition response header). I'm sending this along as a feature request for you, for a way to not have these links return this Content-Disposition, but I can't make any promises.

In any case, I don't have an update on this Internet Explorer issue right now.

@KennelLink Thanks for the feedback! For reference, these parameters are documented in this help article.

[rami2]

Any update?

[Greg-DB]

No, I don't have an update on this issue.

[fredrik80]

We are also now forced to migrate to API v2 and are trying to use the get_temporary_link endpoint. The links generated do not work in Internet Explorer. We would really need a resolution or work-around for this, as we serve a lot of documents on our website based on content in Dropbox.