One more thing:

Can you post your code as it stands now (after your latest modifications) and I will start with that?

    Thanks!!! Neither of my PHP books really mention how to set up links which download images, so I've been looking for online info. Most of the code I've gotten has been from the fpassthru function page at PHP.net: http://www.php.net/manual/en/function.fpassthru.php

    Here's my current code:

    $design_id = $_GET['design_id'];
    $connect_ID = mysql_connect("localhost", "kellym", "merta35") or die("Could not connect");
    mysql_select_db("ily_digitizing");

    $sql = "SELECT image_ref FROM Designs WHERE design_id=$design_id";
    $result = @($sql, $connect_ID);
    $image_ref = @mysql_result($result, 0, "image_ref"); // relative URL of image
    $file_name = basename($image_ref);

    // translate file name properly for Internet Explorer.
    if (strstr($_SERVER['HTTP_USER_AGENT'], "MSIE")){
    $file_name = preg_replace('/./', '%2e', $file_name, substr_count($file_name, '.') - 1);
    }

    // make sure the file exists before sending headers
    if(!$fdl=@fopen($image_ref,'r')){
    die("Cannot Open File!");
    } else {
    header("Cache-Control: ");// leave blank to avoid IE errors
    header("Pragma: ");// leave blank to avoid IE errors
    header("Content-type: application/octet-stream");
    header("Content-type: image/jpg");
    header("Content-Disposition: attachment; filename=\"$file_name\"");
    header("Content-length:".(string)(filesize($image_ref)));

    fpassthru($fdl);
    }

      Are you using a Mac and IE for the Mac?????????

      IE for the Mac Officially Sucks with downloads and causes many problems.

      Before you go off the deep end, prove where the problem is:
      Try using your existing code with Netscape, Safari or Firefox for the Mac. If it works (as I suppose it will), then you have isolated the problem to the browser. There are nasty little workarounds if that's the problem.

        I'm using IE on a PC. I tried viewing the downloaded image in Netscape and received the following error:

        The image “file:///C:/Documents%20and%20Settings/default/Desktop/060904_27_car.jpg” cannot be displayed, because it contains errors.

        It appeared as a broken image in Opera.

        I thought maybe there was something wrong with the uploaded image, but when I view the image on the server with IE it appears fine. So, the errors must be occurring somewhere during the download.

          in your previous code you have 2 header declarations for content type. only one of them will work. image/jpg is not actually a recognized mime type, image/jpeg is the actual mime type.

          after all your sql code, try this, it worked for me in both ie and mozilla

          header("Cache-Control: ");// leave blank to avoid IE errors
header("Pragma: ");// leave blank to avoid IE errors
header("Content-type: image/jpeg");
header("Content-Disposition: attachment; filename=\"$file_name\"");
header("Content-length:".(string)(filesize($image_ref)));

echo file_get_contents($image_ref);

            You wrote:

            but when I view the image on the server with IE it appears fine. So, the errors must be occurring somewhere during the download

            OK:
            Are you SURE that the data inserted in the database == the data of the image??

            Are you SURE that the data downloaded <> the data on the database?

            You might want to post your file to database blob loading code.

              I'm sorry I'm not being more helpful with my comments. I'm fairly new at this and so don't really know how to debug.

              The data stored in the server file system is identical to the image/data that was uploaded. I can view it with IE and the file size is exactly the same (3519 bytes). How can I tell if the downloaded data is the same as that on the server? When I download it and save to my desktop the size of the file grows slightly (3899 bytes). Should this be the case? Netscape still says the file has errors, but then why can Photoshop read it?

                The data stored in the server file system is identical to the image/data that was uploaded.

                Have you done a byte for byte compare?

                I can view it with IE

                ?? How do you do this exactly?

                and the file size is exactly the same (3519 bytes)

                ?? what exactly are you comparing here that is 'exactly the same'?

                I see that you are making a file with this command:

                if(!$fdl=@fopen($image_ref,'r')){

                You need to open this as a BINARY type file:

                if(!$fdl=@fopen($image_ref,'rb')){ // NOTE the 'b'

                from the manual [man]fopen[/man]
                Unix based systems use \n as the line ending character, Windows based systems use \r\n as the line ending characters and Macintosh based systems use \r as the the line ending character.

                If you use the wrong line ending characters when writing your files, you might find that other applications that open those files will "look funny".

                Windows offers a text-mode translation flag ('t') which will transparently translate \n to \r\n when working with the file. In contrast, you can also use 'b' to force binary mode, which will not translate your data. To use these flags, specify either 'b' or 't' as the last character of the mode parameter.

                  To kelly649:

                  I just checked this thread again, and saw that your problem had already been resolved by drew010 since last we spoke. This is just some follow-up info:

                  Using:

                  header("Content-type: application/octet-stream");

                  instead of:

                  header("Content-Type: image/jpeg");

                  may or may not have some impact on forcing a download via the browser, which is what you had described was your end goal. application/octet-stream is a generic content type and may fool a browser into downloading the content. If you choose to use it, be sure to follow it up with:

                  header("Content-Disposition: attachment; filename=\"$file_name\"");

                  to suggest to the browser a filename and extension for the download, naturally.

                  I did a few run throughs with appliation/octet-stream. "d" indicates the browser downloaded and "b" indicates the content was displayed in browser. All downloaded file sizes were the same number of bytes as the source binary (a jpeg):

                  Linux
                  Konqueror 3.0.0-12: d
                  Mozilla 0.9.9: d
                  Netscape 7.1: d
                  Netscape 4.79: d

                  Win2k
                  IE 6: d
                  Netscape 7.1: d

                  Mac OS X 10.3.4
                  Safari 1.2.2: b
                  IE for Mac 5.2.3: b
                  Netscape 7.1: d

                  I tried everything with:

                  fopen($image_ref,'r')

                  and then with:

                  fopen($image_ref,'rb')

                  and it did not affect the behavior of the browsers to display gibberish, but I only tested on a single Win2k box with 2 browsers... PHP manual best practices says to use 'rb' so do it (credit to nemonoman for pointing it out first). However, that wasn't the root cause of your problems as I suspected and drew010 confirmed by testing.

                  I would like to see the code that you use for uploading the file to your MySQL db as I'm interested in what you did to insert into a BLOB. Please post after you read this.

                    I know that this was solved, but I spent ages trying to find a solution to this problem, so hopefully it will help others too.

                    A simple way to solve the Mac IEimage display problem - apart from deleting IE completely, and in contrast to others who say it is bad to store images in a database, this seemed to work.

                    Set the content type header as image/.jpg and use only jpegs, rather than using image/$type or image/jpg.

                    Mac IE then picks it up, and so does IE on other less pleasant platforms.

                      a year later
                      Write a Reply...