I have the following code

  while ($file = $result->fetch_assoc()) 
	{
	$name = $file['name'];
	$type = $file['type'];
	$size = $file['size'];
	$path = $file['path'];
	$filepath = $path . $name;

header("Pragma: public");
header("Expires: 0");
header("Cache-Control: must-revalidate, post-check=0, pre-check=0"); 

header('Content-type: ' . $type);
header( "Content-Disposition: attachment; filename=".basename($name));

header( "Content-Description: File Transfer");
    header('Accept-Ranges: bytes');
    header('Content-Length: ' . $size);
@readfile($filepath);

}

I get the forced download dialog; however, it seems that the file being sent is basically just the download.php script (the html head tags prior to the php code) I created and not the file from the uploads folder.

My Download link basically looks like

		echo "<a href=download.php?id={$uploads['id']}>
               {$uploads['title']}<br />
                </a>";

Can anyone please give me a hand with this. I've tried everything I can think of.

    You might want to try this for some debugging right after you define $filepath:

    $filepath = $path . $name;
if(!is_readable($filepath))
{
   die("$filepath does not exist or is not readable");
}
      NogDog wrote:

      You might want to try this for some debugging right after you define $filepath:

      $filepath = $path . $name;
if(!is_readable($filepath))
{
   die("$filepath does not exist or is not readable");
}

      Tried it and all seems good.
      I even went down and added

      $filepath = $path . $name;
if(!is_readable($filepath))
{
   die("$filepath does not exist or is not readable");
}
else
{
echo "$filepath does exist and believe it or not, it's readable"
}

      I get the message that it exists and is readable.

      Could it be a problem with my download link code?

      		echo "<a href=download.php?id={$uploads['id']}>
               {$uploads['title']}<br />
                </a>";

      Reason I ask is that, if I upload a word doc (or txt for that matter) then go to download it, what I get is a file named correctly; however, it only has the three html head tags to the download.php file itself within it.

        Seems like I have the same problem this gent had

        http://www.phpfreaks.com/forums/index.php?topic=111377.0;prev_next=prev

        Only problem is that when I try to do what resolved his issue, it does open the correct file, only all garbled

        e.g.
        Low &#65533; A Client has a problem to which only affects them and does not affect workflow. An issue of a &#65533;Low Severity&#65533; would be something to the likes of: &#65533;My mouse with a Word Doc

        &#65533;&#65533;A&#65533;&#65533;1&#65533;&#65533;&#65533;&#65533;RL&#65533;EX&#65533;]&#1094;X3E&#65533;&#65533;q.4aUC&#65533;&#65533;&#65533;uJ&#65533;&#65533;pce&#65533;G*&#65533;&#65533;k&&#33979;u]&#65533;&#65533;u&#65533;(.A&#65533;A&#65533;&#65533;&#65533;&#65533;*&#28995;&#65533;6B&#65533;sNgq77&#65533;&#65533;w&#65533;A30&#12454;X&#65533;&#65533;5FC&#65533;L:&#65533;&#65533;&#65533;w is what I get for images

          What the browser does with files it receives is governed by the Content-Type: header contained in the response. Have you checked that this is actually correct? For example, if the client does not recognise the content type at all, it will treat it as equivalent to "application/octet-stream", and ask you what you want to do with it. Or if you're sending an image file but the content type is "text/html", you'll just get an attempt to render the raw binary data as HTML - which never works.

          (One tool I've found convenient for looking at header issues is Firefox's LiveHttpHeaders extension; you get to see exactly what headers are being sent back and forth, without needing to stick potentially intrusive debugging statements.)

            Write a Reply...