Content-Disposition header for binary downloads

[philippguertler]

Currently every binary download response has the Content-Disposition header set to attachment, forcing the browser to download the file when linked directly. Some times it makes more sense to let the file be viewed directly in the browser.

Here are some suggestions:

• Remove the header and use the download attribute of the <a> tag to make the browser download the link (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#Attributes). This does not work cross-origin.
• Make the header inline for some hard coded content types (what you suggested)
• Make the headers somehow configurable - for some projects it makes sense to download a pdf file, for others it makes more sense to have it inline.

[philippguertler]

From @xxyy in Gitter:

I've just seen that Moodle seems to do the download thing by appending a query parameter ?forcedownload=1, which might also be an option, depending on why Content-Disposition was originally added / how it is currently used

[literalplus]

It seems that the header was initially added in this commit, which sadly doesn't provide context as to why it was. It's not mentioned in the changelog either.

As @Jotschi mentioned on Gitter, it would probably make sense to align the behaviour to common web servers. Looking at the Google results for e.g. Apache, the only things that pop up are how to make it add the header. Also, in the current version of the (main) source, the only mentions of the header are for form data. Similar results for nginx and IIS. Hence, it seems like major web servers don't handle/send the header at all by default.

With this, not sending it might be a sensible default behaviour, but it really depends on which use-case caused it to be added in the first place.

Since, for the binary download request, there are already some query parameters, and controlling responses via query parameters seems to match the general spirit of the REST API, adding the query parameter switch seems like the best option to me, given what I know about the context, and also respecting that some people might already be depending on the existing behaviour.

[Alykoff]

The one more cause do something with Content-Disposition header:

• if filename contains a letters (example: russian utf-8 letters) that outside the ISO-
  8859-1 character set (see RFC 5987, stackoverflow discussion) this file won't save with properly name (all russian letters may be replaced to _ symbol).

[Jotschi]

Suggested change for content-disposition header was released in 0.35.0. I'll keep the issue open since I want to address the Content-Disposition behavior separately.

[jrofurtado]

Why not change content-disposition: attachment; filename="filename.pdf" to content-disposition: inline; filename="filename.pdf"
With this change the pdf file opens in a new tab (default behavior), and when saving the filename is used instead of the fieldname.
Tested in Chrome and Firefox and it works when saving the document