It is done for security reasons. file.php mostly serves user content, and as such it does several security checks to prevent certain kinds of attacks, especially with older browsers. It also prevents things like code execution (On badly configured servers) as the uploaded files are not directly executed, but the script reads them from the filesystem before sending. File.php also does several permission checks to see if the requested attachement is actually visible for the user who requested it.thescott wrote: ↑Mon Mar 12, 2018 4:33 pmWhy is it even done the other way by default? It is so incredibly inefficient. I don't want the entire PHP engine called every time someone views an image?
The "download/file.php" script is the biggest resource hog in my logs by far. It's wasting so much of my CPU.
Interesting. Why don't the security precautions apply to remotely linked avatars? I didn't realize non-private jpg files could be so dangerous to serve as static jpg files. I also feel like there must be a way to validate the jpg file once upon uploading and saving to the server, rather than loading the PHP engine and doing the checks every single time the image is served. The same goes for various other image formats like png.
Because those are linked and thus can't be (malicously) parsed by PHP or whatever.
That's a wrong conclusion.
The content isn't checked every time. The access permission is, and after that the avatar filedata is passed thru - the avatar file itself is not accessible from the outside.
Doing it that way is essentially what's needed for a board admin who wants some or all avatars to be private or restricted.
Nobody will build an extension if they don’t know about it. You should make an Extension Request.
Holy cow! And you guys doing it for security reasons? Now I will edit the code and will be unable to apply your updates because of it. And the whole point of security patches goes down the drain...To illustrate this point we can think about the following two situations: serving a static asset (like a CSS file) versus serving content retrieved from FCGI/CGI or a proxied server. The former is predictable, namely the event MPM has full visibility on the end of the content and it can use events: the worker thread serving the response content can flush the first bytes until EWOULDBLOCK or EAGAIN is returned, delegating the rest to the listener. This one in turn waits for an event on the socket, and delegates the work to flush the rest of the content to the first idle worker thread. Meanwhile in the latter example (FCGI/CGI/proxied content) the MPM can't predict the end of the response and a worker thread has to finish its work before returning the control to the listener. The only alternative is to buffer the response in memory, but it wouldn't be the safest option for the sake of the server's stability and memory footprint.
Code: Select all
$inline_link = $filename; ... $thumbnail_link = $filename;