Done

Done. You can use the new VFS::readFile() method to get a local file 
for use with x-sendfile. With the file backend it'll just return the 
local filename - a much cleaner solution for vfs-direct that should be 
just about as fast.

Chuck, assigning to you since you said you had VFS api changes to 
support this...
you can kick it back to me if I am mistaken :)

Yep, exactly.  What I'm suggesting is to keep it as an *option*, in 
addition to the X-Sendfile, for those sites that are OK with the 
photos being accessible without permissions checking.

If not, I don't feel strongly about it. It was just a thought.

Which is good because it allows us to check permissions. If we could 
shortcircuit permission checking even better, but at the moment 
permissions aren't checked at all. I don't know if we deem security by 
obscurity through hard to guess path/file names sufficient.

Would it still be worth keeping vfs-direct as an option though for 
those sites that are OK with allowing it?  For Ansel, at least, it 
would save having to load an Ansel_Image object from the database just 
to get the VFS path to send with X-Sendfile header...

It's also more flexible than vfs-direct, since we can use it anytime 
it's more efficient to get a local file out of the VFS - with the FTP 
backend, for example.

I have some ideas on API changes to VFS for this and then 
BC-compatible ways to use them in Ansel, Gollem, maybe IMP too.

...although just a note that mod_xsendfile for Apache is 2.x only.

From Jan:
How about deprecating vfs-direct in Ansel for X-Sendfile support?
http://tn123.ath.cx/mod_xsendfile/
Works with both Apache and Lighttpd, fixes the permissions problem,
and the admins don't have to do much more configuration than with the
vfs-direct feature.