Hi all,

I am currently running into issues with the i.php script on a vanilla LAMP installation. The point is that we add a lot of images to our albums automatically, which will then not be present in the cache. The images are rather large (they are meant for downloading, not display - but we use the gallery for the thumbnails and metadata).

The current approach of parallel "if the image does not exist in the cache, generate a thumbnail" on LAMP will almost immediately eat all available memory and swap (in my case PHP has an allowance of 500M, with 16G available).

Calling the i.php script with different s parameters seems like a great DOS attack vector too.

I would 'fix' this for my system to return a predefined 'thumbnail currently not available' picture URL when memory is low or too many instances are running, queueing the requests for the future. But I'd like to hear if you can suggest a better solution. Calling the scripts upon import is certainly an option to generate the commonly required thumbnails, but I'd like to make sure that the script is safe enough when change happens or it is called by a client.

The real fix is actually still not to use images larger than your server can handle.

If you want to provide fine data images download maybye consider to store these fine data files in the uploaded folder or elsewhere for example.

One reason for the i.php parameters is flexible theming. It should not be possible to execute this i.php script from outside (given that the server is configured correctly and the permissions are set not too loose of course).

If you know of a way to tell when memory is log in a PHP script, please let us know. But maybe a better approach for you would be to limit the PHP threads so that you do not get such an overload of doing many impage processings at a time.

Thanks for your quick replies. And I apologize for my slow ones.

> It should not be possible to execute this i.php script from outside...

Hmm. Did I misconfigure the server then? Currently, when a thumbnail exists in the cache, the image URL points to this file directly. If it does not exist, it points to i.php with its parameters, all exposed to the user.
It may be a problem restricted to the zpfocus13 theme I am using, if it is not a general one.

Thanks sbillard for the suggestion with the PHP threads. I'll try that. I'm just not happy with the implications on user experience. Still would prefer to get rid of the calculation-intensive user-facing scripts.

The theme accessing this url is not "outside". I was referring to Zenphoto context which themes belong to. They of course need to access that as this is the url to generate processing images if they don't exist already. Your server should of course be allowed to access but no one from outside.

To clarify: The thumbnails (I checked that it is not theme-specific) are created as a link in the form http://host/zp-core/i.php?a=album&i=image.jpg&w=160&h=120&cw=160&ch=120&q=85 - this is not accessed by another script, but presented as image URL to the user. If I disable access, the image will not load.

Yes, that is the link to process images that are not resized yet. If they are you get the link to the cached one directly.

Probably it was too early today for me when I wrote my responses regarding outside and inside.. I don't think there is a problem with that. Since the i.php file is within zp-core it should not be possible to execute it from another server. Sbillard is the actual expert on this I admit.

I see where you are coming from. Sorry. I have been toggling mod_rewrite a few times while evaluating, and only understood now how the core scripts are hidden using mod_rewrite and this index.php mechanism.

I guess it is reasonable to assume it is activated and working.