Feature Request: Setting Content-Length header for files being downloaded

I would like to bring to your attention an issue regarding the Content-Length header. Currently, when accessing files through links such as: https://bonndata.uni-bonn.de/api/access/datafile/ID (as well as via persistentId), the Content-Length header is not being set.

This leads to problems with large file downloads (e.g., files over 20GB in our case), where only part of the file is downloaded without the download manager detecting the error.

I understand that using S3 is recommended for large files and likely avoids this issue, but I believe it would be beneficial to address this for file storage as well. Additionally, while I recognize that it may not be possible to calculate Content-Length when zipping files on the fly, this should be feasible for static files.

What kind of user is the feature intended for?
API User, Guest

What existing behavior do you want changed?
Adding Content-Length in response header

What do you think?

Thank you!
Sergej

Start with the /api/access/datafile/ID and persistentId download entry points described in the issue, then trace how responses are produced for static files versus files zipped on the fly. Done means static file downloads include a Content-Length response header while on-the-fly archives retain their existing behavior.