Child Item

What is the format of the file downloaded via API?

I download the file through Dropbox API at the server side of my app in the following manner:

// setting variable for buffering
let fileBuffered = '';

// authentication
const dropbox = dropboxV2Api.authenticate({
token: process.env.DEV_DROPBOX_SECRET_KEY
});

// configuring parameters
const params = Object.freeze({
resource: "files/download",
parameters: {
path: `/${customerFileFolder}/${fileName}`
   }
});


// download
let dropboxPromise = new Promise(function (resolve, reject) {
dropbox(params, function (err, result) {
if (err) {
reject(err);
} else {
resolve(result);
}
}).on('data',function(data) {
fileBuffered += data;
})

At the end of the process I get the content of the PDF file that I'm trying to download in the fileBuffered variable. The lenght of the string (132,596 bytes) in the variable is pretty equal to the size of my PDF file (139,694 bytes). That's what I get in the debugger:

Now I need to download the file to a client. I assume that the file is binary and I have to convert it into base64.

// convert to base64
const file = `data&colon;application/pdf;base64, ${Buffer.from(downloadResult.fileBuffered).toString("base64")}`;

res.setHeader("Content-Type", "application/pdf");
res.setHeader("Accept-Encoding", "base64");
res.send(file);

I get a much bigger file (252,678 bytes) on a client side and it opens as empty file in Acrobat Reader. What I'm doing wrong?

Find more posts tagged with

API

Abuse

Comments

Greg-DB

The /2/files/download endpoint is a "content-download" style endpoint, meaning that when the call is successful, the requested raw file data is returned in the response body, with the corresponding "Content-Type: application/octet-stream" header.

That's what you're seeing when you print out your "fileBuffered" variable; that's the data for the requested file. (For example, "%PDF..." is the beginning of the actual PDF data.)

Exactly what you do with the data from there is up to you and will depend on your app and what web framework you're using, for example, so I can't really offer exact guidance on what you should do from that point. You don't necessarily need to re-encode it with base64 unless your use case specifically calls for it for some reason though. Perhaps for your use case you should just send fileBuffered down, along with a "Content-Type: application/octet-stream" header as well?

Inter80801

Greg, thank you for your prompt response. I fully understand that there is no issue with Dropbox API and response (let's call it fileBuffered) that I get on my server-side is accurate. Regardless is I send "Content-Type", "application/pdf" or "Content-Type", "application/octet-stream" I get a strange response on my client-side

The fileBuffered size on a server-size is 132,597. The some how it grows to 254Kb when sent to a client-side. It is clear that there is no issue with Dropbox API but maybe you know how to tacke the issue?

Server-side

const file = fileBuffered;
res.setHeader("Content-Type", "application/stream-octet");
res.send(file);

Client-side

function documentFileDownload(fileName) {
const ip = location.host;
let request = $.ajax({
type: "POST",
url: `${http() + ip}/documentFileDownload`,
headers: {
"Accept": "application/stream-octet"
      },

data: {
fileName: fileName
      },
error: function (err) {
console.log("ERROR: " + err);
      }
   });

console.log(request);

return request;
}

Greg-DB

Unfortunately I can't provide support for that side of the operation, since it's not related to the Dropbox API.

I do notice you reversed "application/octet-stream" as "stream-octet" in your code though.

Inter80801

Thank you Greg,

The reversed "application/octet-stream" was typo and it wasn't an issue. I found a solution. Thank you for your help!