Actually, on second thoughts, I'm going to leave this as it is. It's an obviously contrived example and is_file() isn't necessarily sufficient anyway, since it doesn't cover links and special files.

Closing won't fix.

The example may not be so contrived after all. I found the example when I was looking for code to do just what the example does. Before submitting the documentation problem report, I used the example almost verbatim in a project:
http://sermonsontheweb.svn.sourceforge.net/viewvc/sermonsontheweb/trunk/Web/ChurchWebSite/Sermons/Download.php?revision=199&view=markup
I noticed the problem when performing security testing.

There are more elegant solutions with rewrites, but the approach in the example is simple and very portable.

Regarding is_file, perhaps links and special files cases will be OK. If links would be followed, and the stream from special files would be read, that would be appropriate in most scenarios.

Don't get me wrong, it's certainly possible to make the example work with links and special files as well.

My concern is that we're then complicating an example that's specifically demonstrating the usage of readfile() with a Content-Disposition header -- down to having an explicit line at the top defining $file as something that's obviously the name of a file, not a directory. I just think any potential change would only make the intent of the example less clear than it already is.

I see what you mean about the hard coded file name being contrived. Still, taking the example at face value, it's saying if you put a file in some exact location on the server, this code will let you download it. Hence the example checks that the file really exists. I don't think it muddies the intent for the example to also check that what lives at the location is really a file.

Since it doesn't add any complexity to the example, I would get as close as you can to demonstrating best practice.