dynamic image problem

[pricethat]

wondered if anyone else can help or has the same problems, we basically inport images onto our server from the networks data feeds. Once imported we use the GD library (well something similar) to reprocess the images into correct thumbnail sizes to keep our site consistent. Problem is that merchants are using urls like:

http://www.avonshop.co.uk/getimg.asp...n=ProductImage

for example, which is not a file path to an actual image, its a file path to ascript which outputs an image, quite different when trying to import an image.

Does anybody have any clue about what methods we could use to import such an image directly from the server, what commands to use, we cant use a get command on this type of image and also even when we do its not clear what the file type is to allow our script to reprocess it, we need clear urls to images and this looks like something we cant get past.

At the moment we are not importing more than 200,000 products because we dont have images for them. (our theory is if we are going to try and sell something to someone the least we can do is show them what the damn thing looks like)

Also im pretty pissed with this whole thing as it shows that the people that either make the files, or the networks themselves have no real understanding how affiliates use the feeds, i have spoken to others about this subject and it is the same for them. Surely if the images are on the server anyway they can provide the real file path to them and not this nonsense scripts all the time.

[dmorison]

If your server is running PHP >= 4.3 you could fetch the file as raw data, use the Magic Mime function to detect the type, and then use the appropriate GD (or equivalent) import function....

PHP Code:

<?php
    $url = "http://www.avonshop.co.uk/getimg.asp?sid=6732&fn=ProductImage";    
    $src = fopen($url,"r");    
    if ($src)
    {
         $dst = fopen("tmp/imagedata","w");        
        while(!feof($src))
        {
            fwrite($dst,fread($src,1024));
        }        
        fclose($src);    
        fclose($dst);
    }
    echo( mime_content_type("tmp/imagedata") );        
?>

(tmp/ must be writable by the PHP instance of course). If you don't have PHP > 4.3 could another option be to have a guess at the mime type and just keep trying different import functions until one works?

Merchants should check that their scripts at least return the correct MIME type, and preferably take it a step further and use rewrite software to generate URLs that look like a static image file even if the data is actually pulled from a database.

[pricethat]

Thanks for the help, is most kind of you, i'm appalled at the feed quality in general, i think for the most part the merchants and networks have no real understanding of how these feeds are even used..

When i first started this i thought easy import job, now after more than 100 rules later and god knows how many data correction scripts im still having minor problems.

I did manage to play clever and add a perameter to the end of these urls like &imagetype=.jpg and .gif and .png which was enough to fool the import scripts but it took so long to do an import if was getting a joke so will give your way a try.

Still i guess it will be worth it in the end , thanks for the help, will reciprocate when i get the opportunity.

[futureweb]

I think the reason behind it is so they can change product images on a global scale without everyone downloading the csv over and over.

Superb soloution though nice and slick with php would of had a lot more lines in asp to get the same result.