Mastodon Account Archives
TL;DR Sometimes mastodon account backup archive downloads fail to download via browser, but will do so via fetch with some flags in the terminal. YMMV.
the following are notes from recent efforts to get around browser errors while downloading an account archive link.
yes, surely most will not encounter this issue, and that's fine. there's no need to add a "works fine for me", so this does not apply to your situation, and that's fine too. however, if one does encounter browser errors (there were several unique ones and I don't feel like finding them in the logs).
moving on... some experimentation with discarding the majority of the URL's dynamic parameters, I have it working on the cli as follows:
» \fetch -4 -A -a -F -R -r --buffer-size=512384 --no-tlsv1 -v ${URL_PRE_QMARK}?X-Amz-Algorithm=AWS4-HMAC-SHA256
the primary download URL (everything before the query initiator "?" has been substituted as ${URL_PRE_QMARK}, and then I only included Amazon's algo params, the rest of the URL (especially including the "expire" tag) seems to be unnecessary.
IIRC the reasoning there is about the CDN's method for defaulting to a computationally inexpensive front-line cache management, where the expire aspects are embedded in the URL instead of internal (to the CDN clusters) metrics lookups for cache expiration.
shorter version: dropping all of the params except the hash algo will initiate a fresh zero-cached hit at the edge, though likely that has been cached on second/non-edge layer due to my incessent requests after giving up on the browser downloads.
increasing the buffer size and forcing ipv4 are helpful for some manner of firewall rules that are on my router side, which may or may not be of benefit to others.
- Archive directory aspect of URL: https://${SERVER}/${MASTO_DIR}/backups/dumps/${TRIPLE_LAYER_SUBDIRS}/original/
- Archive filename: archive-${FILE_DATE}-{SHA384_HASH}.zip
Command:
» \fetch -4 -A -a -F -R -r --buffer-size=512384 --no-tlsv1 -v ${URL_PRE_QMARK}?X-Amz-Algorithm=AWS4-HMAC-SHA256
Verbose output:
resolving server address: ${SERVER}:443
SSL options: 86004850
Peer verification enabled
Using OpenSSL default CA cert file and path
Verify hostname
TLSv1.3 connection established using TLS_AES_256_GCM_SHA384
Certificate subject: /CN=${SEVER}
Certificate issuer: /C=US/O=Let's Encrypt/CN=E5
requesting ${URL_PRE_QMARK}?X-Amz-Algorithm=AWS4-HMAC-SHA256
remote size / mtime: ${FILE_SIZE} / 1742465117
archive-${FILE_DATE}-{SHA384_HASH}.zip 96 MB 2518 kBps 40s
@stefano looks to be working now :)
Moin. Bei uns insoweit diesem Thema alles normal; Empfehlen 
Drupal Developer Days Leuven 2025: Speaker Spotlight Series 
This session aims to inform developers about possible pitfalls, helping them avoid making common mistakes and providing some information along the way as to why these mistakes are so common and how they can mess with your site.
Register now to secure your spot: 
Most people who run a decent-sized Drupal website have probably heard of Varnish. 
Cache is King: Smart Page Eviction with eBPF
