Download file with Perl on form submit - perl

Question

I am trying to initiate a Save As dialog on a form submit. My form is pretty simple, I'm using Dropzonejs for a drag and drop file, and it looks this:
<form action="action.epl" class="dropzone" id="dropzone" method="post">
</form>
So when the user drops the file it submits and kicks off action.epl. In action.epl, I handle the file and it gets saved to the server. Then I'm trying to spit back out an encrypted version of the file. The encryption is done and I have removed it to make sure it is not the source of the problem, the problem I have now is that I can't get it to download from the server. I have the following (also in action.epl):
$fileName = 'file.pdf';
$filepath= "/server/path/$fileName";
open (FILE, "<$filepath") or die "can't open : $!";
#fileholder = <FILE>;
close FILE;
print "Content-Type:application/x-downloadn";
print "Content-Disposition:attachment;filename=$fileName";
print #fileholder
It's doing /something/ because the submit takes 5x as long as it did without this snippet. What I thought I would get was the "Save As" dialog but nothing happens. This tutorial is where I got my info.
Edit, now I have:
$fileName ='file.pdf';
$filepath = "/server/path/$fileName";
print "Content-Type:application/x-download\n";
print "Content-Disposition:attachment;filename=$fileName\n\n";
open FILE, '<', $filepath or die "can't open: $!";
print while <FILE>;
close FILE;
However, there is still no dialog. I see you have the "$" sigil in your filehandle. I tried that too. But I dont think you need that right?

Answer 1

I see you addressed the typo in the tutorial. The
"Content-Type:application/x-downloadn"
should be "Content-Type: application/x-download\n", to specify the type of the content as "application/x-download" and the "\n" to end the line of the header field.
After that, you're getting into how the browser handles the response. If you provide the Content-Disposition:attachment;filename=$fileName header, you're asserting that the attachment ought to be the given filename $filename. Many browsers will take a peek at the file name, and try to sniff a suitable MIME type for the extension. So, if you're specifying that $filename is a .pdf then to modern browsers, "if it looks like a pdf and smells like a pdf, then it's a pdf". Not only are you saying "this is a pdf" with your specification of the Content-Disposition, you're also providing the name for the file that they download. In most situations, this should prevent the fall-back "save as" behavior.
Your best bet would be to not provide the Content-Disposition. That way, you're not specifying any default name to save the file as, and as such there's no extension for the browser to snoop. Unfortunately, some browsers simply default to the name of the script even if the extension is absurd compared to the contents. In some of the "enterprise solutions" that I deal with in my day-to-day, I get .csv files named as "report.cgi" because they use a MIME type that only Internet Explorer recognizes and they don't provide a Content-Disposition. Buyer beware.
The bottom line is that you can't force the browser to open the "Save As" from the server side unless you have information about the browser and know how to trick it, or you simply don't give it anything to go by (and even then some browsers may have default conventions).
By specifying the Content-Disposition and a filename, you're giving hints as to what the file should be, and what it should be saved as. On the other hand, if you don't give any other hints to the browser other than that the Content-Type is 'application/x-download' then you'll probably get a "Save As" dialog box, but the user will have no idea what kind of content the data is. This puts you at the mercy of the browser's default naming conventions. This is how I get my .csv files as "report.cgi", even when the server is providing a MIME type for csv files (though an IE-only flavor).
What I do is use perl's File::Type and the mime_type function to get the mime type and simply specify a name. If you use the mime_type function for determining the MIME type, and don't specify a file to return, you'll get silly things like .xlsx files being downloaded as zip files, or other absurdity.
How important is it that they get the "Save As" dialog box, because at the end of the day, what file type they choose is irrelevant if the content of the file is not appropriate for the type and they try to open an excel file in acrobat, or vice-versa.
In all of my years of experience doing server side programming, I have always found it futile to try to control the client side.