TYPO3 Core

Georg Ringer wrote:

Thanks for creating the issue, however it is not that easy.

Imagine there are files with 10mb or 200mb or maybe 1gb, using PHP reading this file also means that it will be not so simple to implement

Hmm... Is this really such a (performance related?) problem? The BE module currently automatically renders previews for e.g "pdf"s, too (so a "big" file gets already read by PHP). Shouldn't just reading and echoing a huge file be easier?

If it's really not not possible: What about implementing a "switch" to still deliver files bigger than 500mb directly, but smaller files using my aproach?

I think this issue would be really very useful. I've got several projects where the application e.g. creates invoices or similar (which must be stored public inacessible). In this cases an editor should always be able to access this files using the backend module.

Some notes regarding performance, correct me where i am wrong:
1) rendering thumbnails for PDFs is done by ImageMagick / GraphicsMagick, which are specifically designed for this job. It is also only done once (unless you delete the created thumbnail). PHP is only involved in a way that it tells IM/GM to do the job.

2) Delivering files through PHP needs a lot of RAM, since the file itself is loaded into PHPs memory. So let's say you have a 500MB file, read it in PHP and then deliver it. It will need approximatley 540 MB of memory (in a short test memory_get_usage() for the filelist stated around 36 MB). Thereby a memory_limit of 512MB wouldn't even be enough to handle this request.

3) webservers do not need this amount of memory, because they read the file from your storage with kernel functions and deliver them more or less directly to the network-buffers of the kernel. (this is a highly simplified explanation!). So delivering files through the webserver itself saves a huge amount of resources, especially memory.
4) implementing basic functions of a webserver such as HTTP 206 codes, resume partially completed downloads etc. is a pain and might lead to even more memory usage (amongst other things because you have to read parts of the files)

If you have to deliver files through PHP i would highly recommend to check individual needs regarding your use case combined with the server you are using. Keep in mind that simultaneous users that access those files all need their own memory. So delivering a 500 MB file to 4 simultaneous users will need around 2 GB of your systems RAM. Also, this memory is blocked for the whole time that is taken to download the file by the user, since the php-process has to be running during this time. that being said, your max_execution_time also has to be high enough to deliver the files to the user (which might take a lot of time, if the user does not have much bandwidth).

I would not recommend to implement such a behaviour as a default solution.