Jørn Wildt

One drawback of using images from a database that they have to be loaded each time as there is no content negotiation.
Headers should be added to make caching possible.

As a reference this was on php.net


npdavis at hotmail dot com
24-May-2001 05:45
I build menus using image functions. I noticed that even if you preload the images, some do not always load. In addition the image generation puts a load on the server... the answer? Cache Control headers. These headers will cause IE and Netscape to load all images correctly and also force the proxys and web caches to cache them, allowing your pages to render correctly, AND save you lots of cycles: ) These headers tell both the browser and the ISP caches/proxys to cache the images.

Here is the code:

Header ("Last-Modified: " . gmdate("D, d M Y H:i:s",mktime (0,0,0,1,1,2000)) . " GMT"); // Date in the past
Header ("Expires: Mon, 26 Jul 2040 05:00:00 GMT"); // In other words... never expire the image
Header ("Cache-Control: max-age=10000000, s-maxage=1000000, proxy-revalidate, must-revalidate");//Cache-Control header is ESSENTIAL for forcing Netscape to load all images!... and telling the ISP caches to do the same in this case cache for 1 million seconds.

These headers may or may not be redundant... any input is welcome.

In addition, it is essential for proxys and ISP caches that your re-used images have the same url... IE create a generic image creation script, and feed it parameters. This way your
http://yoursite/imagegen.php?text=home&h=40&w=150&fontsize=13 Home link image has the same url on all of your pages... This will make your images more proxy/cacheserver cache AND browser cache friendly.

To answer the last question first - each image has one, and only one, URL - namely "/index.php?module=photoshare&func=viewimage&iid=ID".

Second - there are some caching control, but it is different from what you ask for.

In your case, where the browser caches the image, you won't be able to see updates when images are modified in Photoshare. You will for instance not be able to rotate an image unless you each time force your browser to reload the image. In addition to this you won't be able to remove access to an image - if a person has seen it, then he/she will be able to view it again and again, even though the author has withdrawed the permissions.

So Photoshare does something else: it uses the "etag" and "last-modified" headers to force the browser to request the image every time you want to see it, BUT, the server will answer "you already have it in your cache" (unless of course the image has been changed in the mean time). So there is a communication overhead everytime you see an image, but the image itself is not transfered unless it has been changed.

This solution places some overhead on the database since we have to make a check on the "last-modified" date for every request. But personally I prefer that solution.

Besides that I think that Photoshare has been implemented in such a way that the image data is fetched from the database, even though it won't be shown, at that can be considered as a bug which should be fixed.

I know this solution still leaves a cached copy on the browser and in this way it is still insecure in terms of access control. But the average user won't notice it.

If anybody has a better solution then I'm listening. I could even make the caching control configurable in the admin menu.

Ok; I have to admit I didn't look at the code. I noticed that loading the images from the database is noticable slower than when loaded directly from the filesystem and I expected it to be the caching mechanism.

Still, I am not totally convinced yet that the approach is really working right now, but it might be the overhead of having the load the whole postnuke framework for those images.

The module really should not fetch the data from the database for the images, that should be fixed indeed.