in reply to Re: Creating inline PDF?
in thread Creating inline PDF?

Instead of the -attachment option, the OP should use the content-disposition header field with a value of inline -- this will generally be respected by browsers. I more often use this to have browsers download the file with the name I want, but this use is within spec.

Those clients that don't respect content-disposition will, as you point out, guess what to do based upon the file extension. Rather than adding unnecessary misdirection of a fake path, why not just call your script myscript.pdf? The server should be interpreting the hash bang, and so who cares what it's called?

#11929 First ask yourself `How would I do this without a computer?' Then have the computer do it the same way.

Replies are listed 'Best First'.
Re^3: Creating inline PDF?
by thomas895 (Deacon) on May 12, 2015 at 03:21 UTC

    The server should be interpreting the hash bang, and so who cares what it's called?
    Depends on the server configuration. It's also probably less confusing for others in the future. It works just fine in almost all cases, so OP has a choice. 

    -Thomas
    
"Excuse me for butting in, but I'm interrupt-driven..."
[reply]

      I used <update>a different that </update> trick in an old CGI: I appended /somename.pdf to the URL, so the CGI was invoked as http://www.example.com/cgi-bin/my.cgi/somename.pdf?func=generate-pdf;some=param;another=param instead of http://www.example.com/cgi-bin/my.cgi?func=generate-pdf;some=param;another=param. Browsers that choose to ignore the MIME type and instead attempted to guess the content from the URL (old Internet Explorer versions) saw somename.pdf, and guessed that a PDF was delivered. Even better, all browsers used somename.pdf as default for the Save-As-dialog.

      The downsides of this trick are:

      • $ENV{PATH_INFO} can't be used, or at least the trailing /somename.pdf has to be ignored or removed.
      • (old versions of) Microsoft's IIS can't handle CGIs with trailing PATH_INFO, resulting in 404 Not Found errors.

      Of course, the clean way is to use the Content-Disposition HTTP header. The value inline should be used if the PDF should be displayed in the browser, if possible for the browser. The value attachment should be used if the PDF should be saved to disk. Browsers are free to ignore the C-D header, but most, if not all, browsers respect it. The C-D header extension named filename should be used to propose a filename. Browsers usually prefer that name over the usual extraction from the URL.

      See also RFC6266, and RFC5987 for filenames containing non-ASCII characters.

      Alexander

      --
      Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
[reply]
[d/l]
[select]

        I used a different trick in an old CGI: I appended /somename.pdf to the URL
        That's actually exactly what I just said ;)

        -Thomas
        "Excuse me for butting in, but I'm interrupt-driven..."
[reply]

In Section Seekers of Perl Wisdom