Update: I think I should explain this a little better. The web browser will think that getpic.pl is simply a directory, and that what it is accessing is a file called bobo.jpg. If you return the right headers, the browser will think that it is retrieving a static jpeg. Depending on how the browser determines whether or not to reload the picture, that may be all that you need. On the other hand, some browser will request the files headers in order to check modification time, file sizes, and whatnot. You need to be prepared to fake those headers if necessary.

--
IndyZ

You don't need a handler to do what you want. Use the path_info method from CGI.

Write a CGI script img (or whatever) whose sole purpose is to feed user images. e.g:

#!/usr/bin/perl -w

use strict;
use CGI;

my $q = new CGI;

my ($user) = split m!/!, $q->path_info();

# database connection stuff here ...
# fetch $pic from database for $user

pint $q->header("image/jpeg"), $pic;
[download]

I like the database + filesystem approach, mostly because it plays to the strengths of the different vehicles. Apache + browser is a very mature system for delivering slowly-changing information efficiently, so i try and use it for that. It isn't optimal for volatile data - just as handmade html isn't - but here the database output is ideal, so I write the world's 23,902,371st content management system.

I think pictures fall into the first category. They don't change much, they're never edited in situ, they're not analysable or indexable and they need no formatting that they don't already have.

In this context using the filesystem is a natural part of the http sequence: the page generated from the database triggers the subsequent requests for images. To have those requests go back to the database seems unnecessary when you've got such a good image delivery mechanism sitting there already. You don't even need to manage a folder structure: dump everything in one place and use the database metadata to update and delete it.

An analogy: consider what happens if you succumb to a broadband evangelist and add video clips to the player profiles. As well as delivering proper image headers, your database system will have to be able to hold and stream the bulky new clips. It's possible, but rather redundant when there are perfectly good mechanisms for streaming it already and they only need to be told where it is.

I think this is a case where two heads are actually simpler than one, given their different strengths. The system you describe is structurally more elegant but practically less efficient.