FileDownload R - [[+fd.url]] broken files


FileDownload R delivers broken files via the link. The files can be opened in Windows and on IOS, but on Android devices they are marked as broken (regardless of whether they are .pdf, .jpg or other).

Step to reproduce



<div class="dwn_file">
    <div class="dwn_filename">[[+fd.filename]]</div>
    <div class="dwn_filetype"><img src="[[+fd.image]]"></div>
    <div class="dwn_filesize">[[+fd.sizeText]]</div>
    <a class="dwn_button dwnl_trigger" href="[[+fd.url]]" download="[[+fd.filename]]" alt="[[+fd.filename]]" title="Download File">Download</a>

Observed behavior

If I put a direct link in the tplCustomFile template “/assets/downloads/myfile.pdf” then the file can be downloaded and works correctly, as soon as I use the placeholder [[+fd.url]] the file is delivered as broken.

Expected behavior

I want to use the template shown above with files in different folders. That’s why I can’t enter a fixed URL there. I just don’t understand why [[+fd.url]] isn’t working properly.


MODX Revolution: Version 2.8.5
PHP: Version 8.0
Database: MariaDB
Extra: FileDownload R 3.1.0
Server: nginx


HTTP/2	200
server	nginx
date	Thu, 24 Aug 2023 13:17:15 GMT
content-type	text/html; charset=UTF-8
content-length	13185
expires	Thu, 19 Nov 1981 08:52:00 GMT
cache-control	no-store, no-cache, must-revalidate
pragma	no-cache
x-powered-by	nothing
x-xss-protection	1; mode=block
x-permitted-cross-domain-policies	none
x-frame-options	sameorigin
x-content-type-options	nosniff
permissions-policy	accelerometer=(), camera=(), geolocation=(), gyroscope=(), magnetometer=(), microphone=(), payment=(), usb=(), interest-cohort=()
strict-transport-security	max-age=31536000; includeSubDomains;preload
set-cookie	PHPSESSID=..........; expires=Thu, 24-Aug-2023 18:50:35 GMT; Max-Age=20000; path=/; secure; HttpOnly; SameSite=strict
vary	Accept-Encoding
content-encoding	gzip
x-cache-status	MISS
accept-ranges	bytes

Does this happen with a certain browser on Android or with all of them?

Did you take a look at the file that gets downloaded? Any idea why it’s “broken”? Does it contain content?

From what request are these headers you posted?

This happens with different browsers of different Android devices. E.g. Chrome or the original Android browser.

I looked at the original file and the file downloaded through Android (on Windows I can open both with no problem) and couldn’t see any difference at all.

The header was parsed from the html website itself because I thought the security policy might be important.

I was able to reproduce this issue with Chrome on Android. (It does work however when I use the Firefox browser on Android.)

I have no idea though, why it won’t let me open the downloaded file.

Maybe something with these response headers in the code should be different?

First of all thanks for your effort.

Unfortunately, I don’t know the header well enough to adapt it. Can anyone else support?

Is this a bug with the extra?

I solved the problem by using another extra. You can do this as an alternative, but the problem with FileDownloadR still exists.