lighty's life: Serving Images From A Database

Serving Images From A Database

jan — Fri, 10 Mar 2006 21:58:00 +0000

Kris tells you why this usually a bad idea in his article Serving Images From A Database

"Serving Images From A Database" by Alexander

Fri, 17 Mar 2006 22:16:00 +0000

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.

"Serving Images From A Database" by alex

Tue, 14 Mar 2006 17:27:15 +0000

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

"Serving Images From A Database" by Jan Kneschke

Tue, 14 Mar 2006 10:36:07 +0000

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

"Serving Images From A Database" by alex

Mon, 13 Mar 2006 18:18:15 +0000

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.