a has asked for the wisdom of the Perl Monks concerning the following question:

Clearly OT, but it will be in perl, (need a work space to go w/ the CB) HEAD shows:
Connection: close Date: Tue, 19 Dec 2000 22:30:32 GMT Server: Stronghold/2.4.2 Apache/1.3.6 C2NetEU/2411 (Unix) Content-Type: application/pdf Client-Date: Tue, 19 Dec 2000 20:32:00 GMT Client-Peer: 156.126.44.246:80 Content-Disposition: attachement; filename=image.pdf
Netscape sees the pdf but IE returns:
%PDF-1.2 % âãÏÓ 1 0 obj << /Type /Page /MediaBox [0 0 612 792] /CropBox [0 0 612 792] /Parent 2 0 R ...

a

Replies are listed 'Best First'.
Re: IE trouble
by a (Friar) on Dec 20, 2000 at 04:02 UTC
    So, just to finish up the unholy mess, I'm now trying:
    my $path = "/pacer/bancap/web/images"; my $file = $ENV{PATH_INFO}; $file =~ s#^[^/]*##; $file =~ s#[^/\d-\.\w]##g; $path .= $file; print "Content-Type: application/pdf\n"; my $size = -s $path; print "Content-length: $size\n"; print "\n"; print `cat $path`;
    (yes, the 'cat' will go away) and it works. No reason that I can see. I've even pared it back down to the original header (content-type only) and its still working.

    a

      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";
      }
      
        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

Re: IE trouble
by a (Friar) on Dec 20, 2000 at 02:44 UTC
    Sorry, this was just supposed to be a scratch node to go along w/ a CB conversation (though if you see the problem, er solution, please let me know). You can't post a header to the CB very easily. I'd hoped to find a perl mod that'll handle this, but no luck. I'd delete it if I could ...

    a