Check it out, I found a pretty good tutorial on this!
http://underscorebleach.net/jotsheet/2004/11/stop-image-hotlinking-tutorial-htaccess-apache
help stop people from hot-linking, but also allow certain sites to hotlink!
Generally, I prefer to serve all images through a web script such as PHP or Python. It allows for a lot of neat things such as tracking which images have the most views, referrer requests, unique views, and even restrictive access to the image on a user scale. htaccess isn't flexible enough to do all that. :P
It is actually quite flexible, just not intuitive. All you're looking at is a customlog directive there, and the user/password restriction stuff that .htACCESS was originally designed to do. But it's not really easy to manage like a custom-written thing would be. The downside to your "script everything" method is the processing overhead. If apache is just feeding an image from a file on an optimized system, it can memcopy the image straight from the kernel VFS to the socket without it even going through normal processing. Scripting images is, by comparison, 100 (or more) times as complex. Of course, when you've got CPU power to spare, it doesn't really matter if you go from 30ns to 3ms. :-)
That's debatable actually, if you set up your image cache correctly it's doubtfully 100x slower. It also can depend on many many other factors. For instance, on our primary eCommerce system all our images are stored in the DB, and all headers are custom built, and it's still blazing fast. The processing overhead you refer to may have been a problem back in the 90's, but with machines now days, it's not really enough to matter.
I didn't say 100x "slower" but rather 100x complex. I'm talking at the system-call level. The number of system calls required to process an image request that's scripted (especially if it comes out of a database) involves at least 100x more system calls (complexity) than an optimized request using the properly tuned apache module. I saw a big write up on this somewhere, and I can't find it now, but there's a method available in apache that's similar to the scatter-gather I/O used by the TUX in-kernel webserver. (http://en.wikipedia.org/wiki/TUX_web_server) But even ignoring that special I/O mode, a static request is still WAY less complex than a scripted one, by several orders of magnitude.
Now, as I (and you) said, it's usually negligible on modern computers (when you're not serving something like eBay anyway.) But the perfectionist in me hates to see anything wasted. I also see it as an analogy with a race car and a drive to work. Would you rather commute 1 mile to work, or 20 miles across town? Sure, that used to matter... but new computers are like 500mph cars. What's an extra few seconds or so on the way to work? The catch however, is that that longer route, even though the time difference is very low, is still 20x more complex... what that means is that you have 20 times the chance of running into a traffic jam, or having an accident. In computers this amounts to the fact that very rarely are all parts of a system tuned equally. Usually a bottleneck occurs at a specific point (like the database server) and everything else slows to the speed that runs at. The less things involved in a system, the less chance for things to go wrong, or to get hung up by some "traffic jam."
Okay, this turned into more of a philosophical stance/discussion than an actual answer, and I realize I always end up doing this to Data when he posts something about design/sysadmin stuff. :-) I don't mean to argue or anything, I just have a different opinion, and want to elaborate my PoV. I don't do it to prove that I'm "right" or anyone else is wrong, so I hope no one takes it that way. For all practical, sane-scale stuff, whatever works best for you is infinitely better than "optimizing" for the machine.
I guess I've just learned long ago that simplicity is better than efficiency in most cases. I used to think along the same lines of preferring the other way, and to be honest if I were a large company like ebay I probably would go an even more complex but faster route, that being an actual server built and set up (possibly with custom complied server) just for the images alone.
In terms of the method I was stating, it's the far more flexible method, even if it is a little slower. Using apache config and static files makes it possible to stop hot linking, yes, but note that I was referencing finer grain control than simply prevention. The better of them being the capability of having images that only certain users could access, integrated with the rest of your system (yes I realize that you can in fact gain stats information via apache directly).
Now I do agree. There's no way I'd do this for just some small site which is *just* preventing hot linking to images. However, in the cases of things like needing preventative access to things that require user login for access, or some special users group, it sure as hell comes in handy (note you can just pass the information directly from the file system to the client too, far more efficient than a DB I might add as we've learned from hard experience >.<). For his case though, the static hot linking prevention through .htaccess is probably the best solution.
You don't ALWAYS do this to me. I'm not viewing either as right or wrong, both methods are equally as good, it just depends on the scenario that you're using them in. ;)
FIGHT! FIGHT! FIGHT!!