URLs generated with files_get_temporary_link are not parsed correctly by some applications

[jjsk]

Hi

I'm using files_get_temporary_link to generate a download URL for a file (active for 4 hrs). The link itself appears to lack the filenam. It just ends with long cryptic number. Some browsers do not interpret this URL correctly and save the downloaded files with strange looking/unfriendly names. For example a temp link like this

https://dl.dropboxusercontent.com/apitl/1/AACaHS_H4dB5wyoQGQeFrhn4lKIBU0O0COeHMBg9x3NguJg_9f2_YxKj7B...

is saved as AACaHS_H4dB5wyoQGQeFrhn4lKIBU0O0.mp3 instead of the real file name as appears in the user's dropbox.

Is there any way to force   files_get_temporary_link generate a URL that ends with the actual real file name?

The previous dropbox API *used* to generate friendly links for temporary shares and it seemed to work very nicely.  Would you please consider returning the old style link layout?

[Greg-DB]

Thanks for the post! There isn't a way to force that, but I'll pass this along as a feature request for the old/filename in URL version, though I can't make any promises as to if/when then would be done.

For reference, the filename is included in the 'Content-Disposition` header, which the HTTP client should be using, but it sounds like not all clients are using that unfortunately.

[jjsk]

Thanks for the reply. I opened a ticket for the client program but they don't seem to quite get what the issue is. I.e. why do they need to inspect HTTP headers to find the name of the file the url points to.

If this can be adjusted in the dropbox API it would probably simplify things a little.