lighty's life

It would be great if Lighty'd have special treatment for relative URL redirects. Lets say dynamic request handler returns redirect to relative thus "local" URL to static content. Instead of sendind that redirect back to browser Lighty might serve that redirect the same way if browser sent a new request for that URL in response to a redirect. Saying "redirect" I mean 3xx HTTP response code family.

You mean something like X-LIGHTTPD-send-file ? It is documented in http://trac.lighttpd.net/trac/wiki/HowToFightDeepLinking and in the fastcgi docs.

Yes, that looks like a right solution for me. I overlooked that part of Wiki. Thanks a lot

Serving images from the database is fine -- usually much preferable to having the app manage files in the file system -- as long as you cache the stuff. In our case we rely on Lighttpd's adaptive pass-through support to do this: If the path exists locally, it will be served by Lighttpd; otherwise the request will be passed to the FastCGI process. A URL such as /images/cache/5_48x48.png first goes to the FastCGI process, by way of internal routing. It parses at the file name into an image ID (5), a desired size (48 by 48) and a format (PNG). It retrieves the database content, scales and reformats the image, stores it as /var/www/images/cache/5_48x48.png or whatever. The next time there is a request for this URL, it will be served directly from the file system. If the file goes away, either intentionally (as when the app wants to invalidate the cache, or when you boot the web app on a different system where the cache is empty) or accidentally (as when you accidentally deleted the cache), then the next request goes back to the app again.