File download behavior different betwen Netscape/IE - PHP Development

[Alexander Gilman Carver]

I have written a pair of scripts that are supposed to work together to
display an index of files and then, upon the user choosing the files (with
checkboxes on an HTML form submitted to itself), tar/gzip the file and
send it to them.

To this end the first script performs an exec() call and generates the
archive (it's a random number but we'll call it foo.bar.tar.gz) and then
writes a META tag into the page after it submits the HTML form to itself:

<META HTTP-EQUIV="Refresh"
Content="2;URL=http://server.tld/path/to/sendprogram.php?
archive=foo.bar.tar.gz">

(all on one line of course).

The second script takes in the parameter, sets the headers and tries to
send the file:

header('Content-Type: application/octet-stream');
header('Content-Disposition: attachment; filename="foo.bar.tar.gz"');
header('Content-Length: '. filesize($_GET['archive']);


if ( $file = fopen($_GET['archive'], 'rb') )
{
while ( !feof($file) and (connection_status() == 0) )
{
print(fread($file, 8192));
flush();
}
}
fclose($file);
unlink($_GET['archive']);

(note the above code was taken from user submissions within the online
manuals at [url]www.php.net[/url])

Now the odd part:

If I'm using IE, this works just fine. I submit the form, wait a few
moments, and then the file transfer dialog box pops up and begins the
download. The file is fine and contains no errors.

If I'm using Netscape 7.1, I still get the file transfer dialog box but
then it never transfers the file. I get a zero byte file. If I remove
the unlink() from the second script, it works (but leaves behind the
archive of course).

Does anyone have any idea why this might be happening and what the right
way or workaround might be?

Thanks

[Allan Savolainen]

On Sat, 13 Sep 2003 05:04:06 +0000 (UTC), Alexander Gilman Carver
<agcmehotmail.com> wrote:

Dunno why that happens, but I've used this without problems (except in
Mac IE you must have the filename as the last element in URL, if not
it uses the filename of your PHP script)

header("Content-Type: application/download\n");
header("Content-Disposition: filename=\"$archive\"");
readfile($archive);
unlink($archive);

- allan savolainen

[Kurt Milligan]

Couple of things;

First, I'm not sure why you are going through the "Refresh" step;
why not just send the file right after the exec() call?
Also, the output step could be simplified, so the whole thing might look
like:

$filepath = 'whatever...';
$filename = 'foo.bar.tar.gz';
exec("tar cvzf $filepath/$filename (stuff to be tar'd)");

header('Content-Type: application/octet-stream');
(I'm not sure the other headers are necessary, but maybe...
also, you might try "application/x-gzip" rather than
"application/octet-stream")

$fp = fopen("$filepath/$filename", 'rb');
if($fp)
{
fpassthru($fp);
fclose($fp);
}


Now, I'm not sure this will solve your Netscape problem, but I have seen
similar things happen in the past where the order that things actually
happen aren't always the same as the order they are in the script (and
actually, I had this problem with IE5.5 (PC) and some Mac versions of
IE). What I did to get around it was to write the file to some tmp
directory, then have a cron script run on a regular basis to clean out
files older than X minutes, rather than having the page do the delete.

HTH
-Kurt
[url]http://www.quanetic.com[/url]
Alexander Gilman Carver wrote:

> I have written a pair of scripts that are supposed to work together to
> display an index of files and then, upon the user choosing the files (with
> checkboxes on an HTML form submitted to itself), tar/gzip the file and
> send it to them.
>
> To this end the first script performs an exec() call and generates the
> archive (it's a random number but we'll call it foo.bar.tar.gz) and then
> writes a META tag into the page after it submits the HTML form to itself:
>
> <META HTTP-EQUIV="Refresh"
> Content="2;URL=http://server.tld/path/to/sendprogram.php?
> archive=foo.bar.tar.gz">
>
> (all on one line of course).
>
> The second script takes in the parameter, sets the headers and tries to
> send the file:
>
> header('Content-Type: application/octet-stream');
> header('Content-Disposition: attachment; filename="foo.bar.tar.gz"');
> header('Content-Length: '. filesize($_GET['archive']);
>
>
> if ( $file = fopen($_GET['archive'], 'rb') )
> {
> while ( !feof($file) and (connection_status() == 0) )
> {
> print(fread($file, 8192));
> flush();
> }
> }
> fclose($file);
> unlink($_GET['archive']);
>
> (note the above code was taken from user submissions within the online
> manuals at [url]www.php.net[/url])
>
> Now the odd part:
>
> If I'm using IE, this works just fine. I submit the form, wait a few
> moments, and then the file transfer dialog box pops up and begins the
> download. The file is fine and contains no errors.
>
> If I'm using Netscape 7.1, I still get the file transfer dialog box but
> then it never transfers the file. I get a zero byte file. If I remove
> the unlink() from the second script, it works (but leaves behind the
> archive of course).
>
> Does anyone have any idea why this might be happening and what the right
> way or workaround might be?
>
> Thanks
>

[Alexander Gilman Carver]

Allan Savolainen <raynetedu.lahti.fi> summoned the power of the electron to profess:
| header("Content-Type: application/download\n");
| header("Content-Disposition: filename=\"$archive\"");
| readfile($archive);
| unlink($archive);

I'll give this a try (server's power supply died last night :( ).
Fortunately, the archive name is the last thing on the refreshed URL.

[Alexander Gilman Carver]

Kurt Milligan <junkatnospammilliganshome.net> summoned the power of the electron to profess:
| Couple of things;

| First, I'm not sure why you are going through the "Refresh" step;
| why not just send the file right after the exec() call?
| Also, the output step could be simplified, so the whole thing might look
| like:

Well, I'm doing the refresh step because I want the form back. This is a
replacement for an existing download page. The existing page only
provides links to each file which you perform a right-click/save as (or
similar). The idea of the archiving is to make downloading multiple files
easier.


| $filepath = 'whatever...';
| $filename = 'foo.bar.tar.gz';
| exec("tar cvzf $filepath/$filename (stuff to be tar'd)");

| header('Content-Type: application/octet-stream');
| (I'm not sure the other headers are necessary, but maybe...
| also, you might try "application/x-gzip" rather than
| "application/octet-stream")

I know the Content-Length header isn't necessary but very useful to give a
progress meter for the download.

| $fp = fopen("$filepath/$filename", 'rb');
| if($fp)
| {
| fpassthru($fp);
| fclose($fp);
| }


| Now, I'm not sure this will solve your Netscape problem, but I have seen
| similar things happen in the past where the order that things actually
| happen aren't always the same as the order they are in the script (and
| actually, I had this problem with IE5.5 (PC) and some Mac versions of
| IE). What I did to get around it was to write the file to some tmp
| directory, then have a cron script run on a regular basis to clean out
| files older than X minutes, rather than having the page do the delete.


I had thought of the cron job as well but the files are going to be too
big to leave on the server for a while. Some of them are going to reach
upwards of 1 GB or more depending on how many files are selected for
download. The archive doesn't compress much because the files being
downloaded are very nearly compressed (mostly images). I gain a couple
percent compression by compressing one large tar simply because it gives
gzip more data to work with.

I'll give your script a try as well. If I can support IE and Netscape,
that's all I'm going to worry about. :)