In this new post to his blog Larry Garfield tries to dispel a common misconception in the PHP development world - that the readfile function should be considered harmful and can cause memory issues in your code.

If you're like me, you've probably read a dozen or two articles about PHP performance in your career. Many of them are quite good, but some are simply flat out wrong, or misinformed. One of the old truisms that has been repeated for as long as I can recall is "don't use readfile() if you have big files, because it reads the whole file into memory and your server will explode." [...] There's just one problem with that age-old truism: It's not true.

He created some benchmarks to illustrate the differences between several of the common methods for working with files via the fread, fpassthru, stream_copy_to_stream and of course readfile. He reports the results based on the runtime and the peak memory usage and noted, ironically, that while the times varied slightly, the memory consumption was exactly the same for all of the approaches. Since there's no real reason not to use "readfile", he looks at three reasons why there might be this stigma attached to it (including the issues that could come up with output buffering enabled).

Kae Verens has posted a quick tutorial about serving up files by routing them through a "fetch" script, pulling their contents in one side and back out the other.

One thing I need to do while building the multi-user version of webme is to convert it so file references such as /f/photos/an_image.jpg get transparently converted so they serve correctly, even though the actual file may be located somewhere entirely else.

There's two steps involved - rewriting the URL request for the types of files you'd like to pull through the script (using some mod_rewrite magic in Apache) and make the script to do the actual work. Source for that is included too. Not only can something like this help you keep things organized but it also allows for extra security if you need to store the files outside of the webserver's document root.

Davey Shafik has gotten more than a little excited by the streams functionality in his latest blog post:

PHP streams are absolutely amazing. As mentioned by Elizabeth Smith (a great read if you don't know how to use streams) PHP streams are super powerful. Streams is something that is (to my knowledge) unique to PHP. The closest thing I've seen to it, is Linux's FUSE "user space" (i.e. not kernel module) file systems.

He shows an example of a stream in action and suggests an interface he'd like to see - an automatic connection to the Amazon S3 storage.

Davey Shafik has gotten more than a little excited by the streams functionality in his latest blog post:

PHP streams are absolutely amazing. As mentioned by Elizabeth Smith (a great read if you don't know how to use streams) PHP streams are super powerful. Streams is something that is (to my knowledge) unique to PHP. The closest thing I've seen to it, is Linux's FUSE "user space" (i.e. not kernel module) file systems.

He shows an example of a stream in action and suggests an interface he'd like to see - an automatic connection to the Amazon S3 storage.

On the PHPClasses site today, there's a new post that points out an issue that could happen with dyanamic GIF creation in a PHP script leading to a security exploit.

Manuel Lemos writes:

The problem that was discovered is that you can insert PHP code in the middle of a GIF image. That would not be a problem if it was not for the insecure ways some developers use to serve images upload by their users. Usually, uploaded files are moved to a given directory. If the site then serves the images directly from that directory and preserve the original file name, the site may be open for security exploits.

The problem comes when a user decides to upload an "image" file that's actually a PHP script (ending in PHP even) to the remote system. When this is outputted, it's placed inside the image tag and executed with each page load. Manuel offers a suggestion to prevent the issue - protecting the images directory and using readfile to grab the contents of the file to output rather than just a straight echo.

On the PHPClasses site today, there's a new post that points out an issue that could happen with dyanamic GIF creation in a PHP script leading to a security exploit.

Manuel Lemos writes:

The problem that was discovered is that you can insert PHP code in the middle of a GIF image. That would not be a problem if it was not for the insecure ways some developers use to serve images upload by their users. Usually, uploaded files are moved to a given directory. If the site then serves the images directly from that directory and preserve the original file name, the site may be open for security exploits.

The problem comes when a user decides to upload an "image" file that's actually a PHP script (ending in PHP even) to the remote system. When this is outputted, it's placed inside the image tag and executed with each page load. Manuel offers a suggestion to prevent the issue - protecting the images directory and using readfile to grab the contents of the file to output rather than just a straight echo.