Web Form search and open pdf
 

All,

I'm trying to create a "simple" web-based application that will allow
users to search for pdf files, and when the files exist, the browser
opens the .pdf in the browser. I can get the form to find the .pdf
and open it on a PC, but the filename is still the name of the ".cgi"
script.

I also cannot get my basic version to work on the Macintosh platform.

I've scoured the web for answers, and have pieced together some code
from different sources, but I'm missing two crucial pieces....having
the file show up with the real name (not script.cgi) and getting this
to work on Macintosh OS9 browsers(file is corrupted).

Here's my code:

#!/usr/bin/perl -wT
###########################Find pdf ads based on user submission
use CGI ':standard';
use CGI::Carp qw(fatalsToBrowser);
use strict;

my $files_location;
my $ID;
my @fileholder;

$files_location = "/usr/local/apache2/pdfads";

$ID = param('pdfname');
if ($ID eq '') {
print "Content-type: text/html\n\n";
print "You must specify a file to download.<br>";
print "<br>";
print "<form name=pdf method=post action=../cgi-bin/download.cgi>";
print "New pdf search<br>";
print "<br>";
print "<table>";
print "<tr><td><b>Ad Number:</b><input type=text maxlength=30
name=pdfname size=20></td></tr>";
print "</table>";
print "<input type=submit name=Submit value=View PDF size=15>";
print "</form>";
exit;
}

if (-e "$files_location/$ID")
{
open(DLFILE, "<$files_location/$ID") || die ("Cannot open PDF ad $ID,
try again.<br>");
@fileholder = <DLFILE>;
close (DLFILE) || Error ('close', 'file');
###print "Content-Type:application/x-download\n";
print "Content-Type:application/pdf\n";
print "Content-Disposition:inline; filename=$ID\n\n";
print @fileholder
}
print "Content-type: text/html\n\n";
print "Cannot find PDF Ad $ID, please try again<br>";
print "<form name=pdf method=post action=../cgi-bin/download.cgi>";
print "<br>";
print "<table>";
print "<tr><td><b>Ad Number:</b><input type=text maxlength=30
name=pdfname size=20></td></tr>";
print "</table>";
print "<input type=submit name=Submit value=View PDF size=15>";
print "</form>";
exit;

Re: Web Form search and open pdf
 

<dbmeyers23@yahoo.com> wrote in message
news:1102535017.156092.22810@c13g2000cwb.googlegro ups.com...
> All,
>
> I'm trying to create a "simple" web-based application that will allow
> users to search for pdf files, and when the files exist, the browser
> opens the .pdf in the browser. I can get the form to find the .pdf
> and open it on a PC, but the filename is still the name of the ".cgi"
> script.
>
> I also cannot get my basic version to work on the Macintosh platform.
>
> I've scoured the web for answers, and have pieced together some code
> from different sources, but I'm missing two crucial pieces....having
> the file show up with the real name (not script.cgi) and getting this
> to work on Macintosh OS9 browsers(file is corrupted).

If you just want the PDF displayed in the User's browser's location bar,
then you should have your CGI program redirect to the PDF, rather than
print the contents of the PDF.

http://search.cpan.org/~lds/CGI.pm-3...RECTION_HEADER

Paul Lalli

Re: Web Form search and open pdf
 

"Paul Lalli" <mritty@gmail.com> writes:
> If you just want the PDF displayed in the User's browser's location bar,
> then you should have your CGI program redirect to the PDF, rather than
> print the contents of the PDF.

That only works if the PDFs are under the webserver's document root,
and there are many good reasons you may not want to do that. If
that's not the case, then you do need to use your CGI program to print
it to the browser. In which case to set the name, I have always found
setting the filename in the MIME Content-Disposition header to do the
trick. This might look like (untested);

#!/usr/bin/perl
use warnings;
use strict;
use CGI;
use File::Basename;

my $pdfpath = '/path/to/filename.pdf'
open my $pdf, '<', $pdfpath or die "Can't open $pdfpath: $!";

print header(-type => 'application/pdf',
-content_disposition => 'inline; filename='.basename($pdfpath));
print while (<$pdf>);

-=Eric
--
Come to think of it, there are already a million monkeys on a million
typewriters, and Usenet is NOTHING like Shakespeare.
-- Blair Houghton.

Re: Web Form search and open pdf
 

In article <eto3bygihjg.fsf@wilson.emschwar>,
Eric Schwartz <emschwar@fc.hp.com> wrote:

> "Paul Lalli" <mritty@gmail.com> writes:
> > If you just want the PDF displayed in the User's browser's location bar,
> > then you should have your CGI program redirect to the PDF, rather than
> > print the contents of the PDF.
>
> That only works if the PDFs are under the webserver's document root,
> and there are many good reasons you may not want to do that. If
> that's not the case, then you do need to use your CGI program to print
> it to the browser. In which case to set the name, I have always found
> setting the filename in the MIME Content-Disposition header to do the
> trick. This might look like (untested);
>
> #!/usr/bin/perl
> use warnings;
> use strict;
> use CGI;
> use File::Basename;
>
> my $pdfpath = '/path/to/filename.pdf'
> open my $pdf, '<', $pdfpath or die "Can't open $pdfpath: $!";
>
> print header(-type => 'application/pdf',
> -content_disposition => 'inline; filename='.basename($pdfpath));
> print while (<$pdf>);
>
> -=Eric

redirect to a script that pushes back the pdf (as the o.p. did), but
pass the pdf name in the path info, thusly:

http://www.domain.com/path/to/script/pdfname

every browser i've tried will then use the pdf name as the file name,
since it's at the end of the url. you can access the pdf name in
$ENV{PATH_INFO}. it will likely have a '/' prefix, so you'll need to
deal with that.

works great for me for years.

--
Michael Budash

Re: Web Form search and open pdf
 

Michael Budash <mbudash@sonic.net> writes:
> redirect to a script that pushes back the pdf (as the o.p. did), but
> pass the pdf name in the path info, thusly:
>
> http://www.domain.com/path/to/script/pdfname

That works too, but you probably don't want to use the full path to
the pdf-- otherwise, you've just opened up a huge security risk. Not
that you advocated that, just pointing it out in case someone reading
your suggestion didn't think of it.

-=Eric
--
Come to think of it, there are already a million monkeys on a million
typewriters, and Usenet is NOTHING like Shakespeare.
-- Blair Houghton.

Re: Web Form search and open pdf
 

In article <etoy8g8gs9n.fsf@wilson.emschwar>,
Eric Schwartz <emschwar@fc.hp.com> wrote:

> Michael Budash <mbudash@sonic.net> writes:
> > redirect to a script that pushes back the pdf (as the o.p. did), but
> > pass the pdf name in the path info, thusly:
> >
> > http://www.domain.com/path/to/script/pdfname
>
> That works too, but you probably don't want to use the full path to
> the pdf-- otherwise, you've just opened up a huge security risk. Not
> that you advocated that, just pointing it out in case someone reading
> your suggestion didn't think of it.
>
> -=Eric

absolutely. the only indication of the pdf shold be its name. the script
can handle push its content back from its actual location on the server.

--
Michael Budash

Re: Web Form search and open pdf
 

Thanks everyone, I have an acceptable version of this working.
Michael Budash's suggestion of the redirection solved the problem of
the file showing up with the name as "script.cgi" instead of "xxx.pdf".
This also allows Macs (OS9-OSX browsers) to open the pdf's.....

Re: Web Form search and open pdf
 

In article <1102692163.140732.227850@f14g2000cwb.googlegroups .com>,
dbmeyers23@yahoo.com wrote:

> Thanks everyone, I have an acceptable version of this working.
> Michael Budash's suggestion of the redirection solved the problem of
> the file showing up with the name as "script.cgi" instead of "xxx.pdf".
> This also allows Macs (OS9-OSX browsers) to open the pdf's.....
>

glad to help. like i said, that method has never failed me.

--
Michael Budash