Can't download text file

[igor-lemon]

New Issue Checklist

• I am not disclosing a vulnerability.
• I am not just asking a question.
• I have searched through existing issues.
• I can reproduce the issue with the latest version of Parse Server.

Issue Description

Can't download a text file. The file opens in a browser, I need to save it manually.

Steps to reproduce

Upload some text file. Try to download it by link.

Actual Outcome

Expected Outcome

I want to download the file immediantly.

Environment

Server

• Parse Server version: FILL_THIS_OUT
• Operating system: FILL_THIS_OUT
• Local or remote host (AWS, Azure, Google Cloud, Heroku, Digital Ocean, etc): FILL_THIS_OUT

Database

• System (MongoDB or Postgres): FILL_THIS_OUT
• Database version: FILL_THIS_OUT
• Local or remote host (MongoDB Atlas, mLab, AWS, Azure, Google Cloud, etc): FILL_THIS_OUT

Client

• SDK (iOS, Android, JavaScript, PHP, Unity, etc): FILL_THIS_OUT
• SDK version: FILL_THIS_OUT

Logs

[parse-github-assistant]

Thanks for opening this issue!

• ❌ Please fill out all fields with a placeholder FILL_THIS_OUT, otherwise your issue will be closed. If a field does not apply to the issue, fill in n/a.

[mtrezza]

Thanks for opening this issue!

I can imagine that people have different expectations, depending on how they use the dashboard. Some may want an image for example to be displayed immediately in the browser, others may want it to be downloaded. Changing this one way or the other may disrupt or improve someone's workflow.

Browsers usually have an option to to download a resource instead of displaying it directly in the browser.

For example in Safari on macOS, if you hold the option key while clicking on a link, the browser decides to download it, regardless of what the server recommends. You can try this out by going here and clicking the Raw button in the file header bar.

Conversely, I don't think browsers do have an easily accessible shortcut to display a resource in a browser. So it may make more sense to keep the current behavior of opening resources in the browser by default and give the user the option to use a browser shortcut to download a resource.

[mtrezza]

@igor-lemon can this issue be closed?

[igor-lemon]

If you think that it isn't a popular solution you can close the issue and close the PR.

[mtrezza]

It changes the behavior, but how can we decide which behavior should be preferred? If I read the PR correctly, it sets the content-disposition header to attachment for every file supplied by the file router. That could be a breaking change for existing deployments.

Instead of hard-coding whether the header should be inline or attachment, maybe we can find a more flexible solution, keeping the current behavior in place as to avoid a breaking change.

Alternatively, there is also the HTML <a> element's download attribute that for some browsers even overrides the header, see this. Not sure how other browsers interpret this, but this could move the decision to the front-end, keeping the backend un-opinionated.

[igor-lemon]

Maybe my needs are exclusive, but I really don't need to show the file in a browser.
I think the best solution - set custom headers for the file when we save it or add some option justDownload<bool>. But the problem that we need to save this info about files to some collection/table.
Or maybe a more easy solution just to set some option when we init the Parse Server, if you like this way I can try to implement it.

[mtrezza]

And why don't you use the download attribute?

[igor-lemon]

And why don't you use the download attribute?

Because it doesn't work :)
Parse generates a not strong path to the file (I use Amazon S3 as file storage)

[mtrezza]

What do you mean by "not strong path"?

[igor-lemon]

Sorry, not a direct path

[mtrezza]

Do you mean the path points directly to S3 and not via Parse Server?

[igor-lemon]

Oh, no, I found a problem...
Parse Server doesn't return correct Content-Type header, just return null value.
If I want to set binary/octet-stream type

new Parse.File(`${id}.data`, { base64: base64data }, 'binary/octet-stream');

It doesn't work...

[igor-lemon]

So, I can propose 2 ways:

1. Make binary/octet-stream as default content type (if mime couldn't detect type of file)
   or
2. Add Mime types map as +1 extra config