in reply to Creating inline PDF?

From the CGI documentation regarding the use of -attachment:

Instead of displaying the page, some browsers will prompt the user to save it to disk
Suggested fix: Remove the -attachment option.

There will be browsers that don't have the PDF reader extension properly configured (or set to always download): they will still have it downloaded.

I imagine you might want to suggest a name to the browser for if they choose to download it. I've always done it with path information, linking to the CGI script as: /cgi-bin/myscript.cgi/something.pdf, where myscript.cgi is of course the script itself. You can ignore the path info, no modifications are needed to your script. 

-Thomas

"Excuse me for butting in, but I'm interrupt-driven..."

Replies are listed 'Best First'.
Re^2: Creating inline PDF?
by kennethk (Abbot) on May 12, 2015 at 01:29 UTC

    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.

[reply]
[d/l]
[select]

      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]

In Section Seekers of Perl Wisdom