Xz archive downloads not tracked

General questions
1

I have a strange issue, probably someone has an idea what the reason can be:

We host OS images on our website, previously 7z-compressed, and downloading those were and are tracked very well as downloads, shown in visitor activities and we have a goal defined which successfully counts those image downloads.

Recently we switched to xz-compressed images, with .img.xz file ending, along with hashes with .img.xz.sha256 ending and signatures with .img.xz.asc ending. Downloading any of these files is not tracked by our Matomo at all, they do not appear as any activity. The hash files have a text/plain MIME type, hence are shown as text in browser, but as well Matomo does not get any activity from it. I added test .xz files at a different path/URL, and it is the very same, no .xz file download anywhere at our server is tracked at all, while any other file type download just next to it is tracked fine.

I thought that it might be related to the MIME type, so I tried to set it to be the same as the 7z files, but it does not change something. Since also the hashes and signatures have other MIME types, it actually makes sense that this is not the reason.

I compared the HTTP headers via curl -I to see whether there is any difference between the xz and 7z URLs, but there is none, aside of the expected ones: content-type/length, date, last-modified, etag and such.

We host our website through Cloudflare. One difference was that Cloudflare did automatically assign the 7z MIME type, as the server did not. It did the same for the xz archives, but falsely also assigned application/x-xz for the hash and certificate files, so we do now define them directly at our webserver. I also defined the 7z archive MIME type directly at our sever, to see whether this makes a difference, but it does not.

I cleared the Cloudflare cache every time I did a test. The Matomo frontend is added via Matomo Cloudflare app, so it works for cached and none cached downloads/visits, and it always did reliably, and still does for every other download, aside of these 3 newly added file types, i.e. it works well for gz archives, deb (Debian packages), zip, 7z, media and txt files, all correctly tracked.

I am puzzled what makes the newly added xz/sha256/asc downloads different, so that Matomo does not track them at all. Does anyone have a clue or idea where I could have a look at or how to further debug?

Btw, here some files I can replicate it with: https://dietpi.com/downloads/

  • test.gz and test.xz.gz are successfully tracked as downloads
  • test.xz, test.xz.sha256 and test.xz.asc are not tracked at all, exactly the 3 new file types we started to use to distribute our OS images.
2

Hi @MichaIng
Have a look at:

1 Like
3

Many thanks, now it perfectly makes sense. I was sure that there is a more generic way downloads are tracked than via file extensions.

Not sure if there is a way in JavaScript to know whether the browser offers the target of a link as download or via other external handler. Theoretically if there is no 2nd related tacker request, it is an indicator that it was not a HTML response. MIME types are of course an idea, but AFAIK the response of a regular link is not available to the frontend of the originating page :thinking:.

EDIT: https://github.com/matomo-org/matomo/pull/21386

EDIT2: Okay, I updated our matomo.js accordingly and it works as expected. But as of the Cache-Control header, it is cached for 1 year in browsers, so it will take a while until reoccurring visitors will have these downloads tracked. Does anyone have an idea how to force clearing of the browser cache? Usually I’d use a <script scr="...matomo.js?v=2"> versioning query string so that old cache entries are not used anymore, but there is no way to insert this into the Cloudflare Matomo app. I tried to edit the script tag with another script within the head section, but when this other script runs, the matomo.js script tag is not present yet (it is added by the Cloudflare Matomo app, which is added as another JS script in the head), while when I do this within the body section, the matomo.js may be downloaded already, at least editing the head section won’t have any effect anymore.

EDIT3: PR merged. At least on our case, the few visitors which might have a cached version of the matomo.js seem to have no significant effect, so solved for us.

1 Like