chdir($filepath);
    my $filesize = -s $filename;
   print "Content-disposition: attachment;filename=$filename\n";
    print "Content-Length: $filesize\n";
    print "Content-Type: application/octet-stream\n\n";

    open(READ,$filename) || die;
    while (<READ>) {
        print;
    }
    close(READ);
[download]

Thanks for the replies everyone, so far I have got it working to my satisfaction, but the browser has other ideas, I'm using CGI::Application so the sub in question (with hard coded parameters) is below:


sub do_download {
        my $self = shift;
        my $post = $self->query();
        my $fname = "/storage/surtron/cda/clients/ryan/new/surtron-020
+130-01.zip";
        my $fsize = -s $fname;
        $self->header_props(    -type => "application/octet-stream",
                                -attachment => "blahblah2123.zip",
                                -Content_length => $fsize);
        open(READ,$fname) || die;
        my @fcontent = <READ>;
        close(READ);
        return "@fcontent";
}
[download]

The above code correctly produces the following output

Content-Disposition: attachment; filename="blahblah2123.zip"
content-length: 139124
Content-Type: application/octet-stream

PK {rest of zip file}
[download]

Evidently the browser is not honouring the Disposition header, I'm testing it will IE 6.0.2600.0000. Any further ideas?

Update:
There is a MS support article on this for IE 5.5: FIX: "Content-Disposition: Attachment" Fails for Known Content Types (Q267991) HERE

I just went for a drive to test IE 5.5 with the fix, it recognises it needs to download, then pops up 2 prompts, one for the name of the CGI and one for the name passed in the Disposition header, then it saves the file in some unknown format which winzip doesn't like. Hmmm is there any hope?

Could the code I have provided possibly mangle the data in any way so as to cause it to be an invalid zip file? When I try to recover the zip file I can recover the first 2 files out of the 5 in the archive.

More Updating:
I just changed the code to a crude:

my $filecat = `cat /blah/blah/whatever`;
return $filecat;
[download]

and now it all works :-)

$r->header_out( 'Content-Disposition' => "attachment; filename=$save_a
+s" );
[download]

# determine the http header to send the browser client:
my $user_agent = $q->user_agent; # CGI query object
if ($user_agent =~ m/MSIE/i) {        # for IE users, the following wo
+rks:
    print "Content-Disposition: attachment; filename = $name\n\n";
}
else {                                # for Netscape clients, need to 
+do a 2-pass trick here...
    if ($q->path_info() )    {
        # 2nd pass: collect the extra path info which Netscape client 
        # will use to name the downloaded file:
        print $q->header('application/x-octet-stream');
    }
    else {                        
        # 1st pass: add the name info to the http header path info var
        # and redirect back upon itself for the 2nd pass:
        $q->path_info("/$name");
        print $q->redirect($q->self_url());
        exit;
    }
}
[download]

Hope this helps

..Guv

Make jolly sure that you are checking the contents of param('file'). In particular, make sure that data.cgi?file=../../../../../../etc/passwd does not output bad things to the user.

You may have done this already, or you may trust your authenticated users, but it never hurts to be careful... I have just been bitten in the ass by this, so I speak from bitter (in)experience!

dave hj~

Yes, most definately, thanks for the reinforcement.

Thanks to all who replied, most helpful, keeping to my usual style I normally post what I ended up doing and why:

I've gone with the $ENV{PATH_INFO} idea, because the header stuff caused double prompts and general mess in IE, worked perfectly in Opera though.

However, I'm not actually using the $ENV{PATH_INFO} contents, I'm just calling the CGI in that style and passing the required info via post such as below, 'run' is the CGI and 'cda' is an ExecCGI-d directory:

<form method="POST" action="/cda/run/surtron-020130-03.zip">
<INPUT TYPE="image" src="/images/icon-zip.gif" ALT="Download surtron-0
+20130-03.zip" BORDER="0">
<input type="hidden" name="mode" value="download">
<input type="hidden" name="file" value="surtron-020130-03.zip">
</form>
[download]

This is almost a shortcut I guess, looks neat from the client side and works well in all cases. As long as I check for tainted posts it seems to do what I want.

Update:
I have now changed the above so that the filename hidden field passes a database id instead of the actual filename to make it less h4x0rable.