Not necessarily... All you need is for the httpd daemon to have read access on the file. I took care of the paths, filenames, sizes, etc by using this little snippet: sub DownloadFile {
# $filepath is the directory
# $filename is the name of the file
my ($filepath,$filename) = @_;
chdir($filepath) || return(0);
my $filesize = -s $filename;
# print full header
print "Content-disposition: inline; filename=$filename\n";
print "Content-Length: $filesize\n";
print "Content-Type: application/octet-stream\n\n";
# open in binmode
open(READ,$filename) || die;
binmode READ;
# stream it out
binmode STDOUT;
while (<READ>) { print; }
close(READ);
# should always return true
return(1);
}
I hope that's useful. It has a few extra steps that aren't reeeaalllly needed, but its nice to be on the safe side.
Cheers! | [reply] [Watch: Dir/Any] [d/l] |
The crucial part is the "Content-disposition" parameter.
Incidentally, you should use
Content-disposition: attachment; filename=file
Instead of "inline" if you really want the save-as box to pop up.
It probably won't make any difference, but it could if the user
has a program set up to handle the content-type you're returning (for example, if you're returning a pdf file).
Incidentally, the RFC on HTTP/1.1 only defines behavior with "attachment".
(And that only in an appendix under "Additional Features")
| [reply] [Watch: Dir/Any] |
I had no idea that inline wasn't in the RFC. To be perfectly honest, I haven't even read it. I got the full header by ripping it off a bare telnet GET request and examining the response. I saw a CGI app that did what I wanted (I *think* its the download app at e.themes.org) and tried to mime what it was doing.
One of those things that happen outta mere curiosity...
| [reply] [Watch: Dir/Any] |
could elaborate on how to implement this?
thanks!
fromsir
| [reply] [Watch: Dir/Any] |