First, a stylistic issue: Rather than having $path mean two different things within the same span of code, it might be better write
my $size = -s "$path/$file";
...
print `cat $path/file`;
instead of appending $file to $path.
Next, a robustness issue: Are you really, really sure that "$path/$file" exists? Better to test first and issue an appropriate error message, rather than hiding an error message from cat in the purported pfd stream.
Lastly, a very minor performance issue: why use cat when you can do the same in process with a few extra lines of Perl?
if ( open(PDF, "<$file/$path" ) {
print "Content-type: application/pdf\n";
print "Content-length: ", -s "$file/$path", "\n";
print "\n";
print <PDF>;
close(PDF);
}
else {
print "Content-type: text/plain\n\n";
print "$file/$path: $!\n";
}
| [reply]
[d/l]
[select] |
Thank you dws for replying. The original code and all
the mess that followed was the result of a
2 line shell hack:
echo "Content-Type: application/pdf\n\n"
cat $path
of a cgi script I'd stuck in to test something. As it happened
IE would show raw PDF while NE would show the image. Weird.
As it happens, yes, the pdf exists, a previous cgi (don't ask)
puts the link in only if the image/pdf file exists and I
fully intended to move the mess to a perl script (for billing
and other reasons) once I got the IE fiddle out of the way.
The worser part is, the IE problem went away on its own,
I can only think I was the victim of over caching. It was
pointed out that IE ignores the content-type info and tries
to figure out the incoming type on its own. While I had a
version that worked in NE but not IE, my fixing must've
been hampered by either BillG still mad about that node
from so long ago or some cache problem, where the bad
one kept reappearing. I am now using print PDF> (happily,
I am using that exact filehandle name ;-), though I
wonder if there is a need to use sysread instead of
just open/print.
Actually, I wish either the CB had a scratch node area,
or deleting a node were easier. But thanks for the advice.
a | [reply]
[d/l] |
In an attempt to put a stake through this one: it appears that
the headers:
Accept-Ranges: bytes
ETag: "ac0f-2743f-3a2ebf5b"
cause trouble. I gather these are supposed to be server
generated (in particular the "Entity-Tag" is a server(?)
specific code for a file type; Accept-ranges means the
server'll allow "header and some bytes more" requests),
and either I'm doing them wrong or they confuse both IE
and NE. If anybody has a hint ... here's the final
code, FWIW:
my $debug = 0;
my $path = "/web/images";
my $file = $ENV{PATH_INFO};
$file =~ s#^[^/]*##;
$file =~ s#[^/\d-\.\w]##g;
my $pdf_file = $path . $file;
if ( -s $pdf_file ) {
print "Content-Type: application/pdf\n";
#print "Accept-Ranges: bytes\n";
#print "Accept-Ranges: none\n";
#print "ETag: \"ac0f-2743f-3a2ebf5b\"\n";
#print "Last-Modified: Wed, 06 Dec 2000 22:36:11 GMT\n\n";
my ($size, $mtime) = (stat $pdf_file)[7,9];
print "Last-Modified: ", scalar gmtime($mtime), "GMT\n";
print "Content-length: $size\n";
# print "Content-disposition: attachement; filename=$pdf_file_name\n"
+;
print "\n";
open(PDF, "$pdf_file" ) or die "Can't open pdf $pdf_file: $!";
print <PDF>;
close PDF;
print STDERR "documents: $pdf_file, $size\n" if $debug > 5;
} else {
print "Content-Type: text/html\n";
print "\n";
print "<h1>Error</h1>\n
Image file : $file is missing!!!
<p>
<hr>
";
}
a | [reply]
[d/l] |