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] |
| [reply] |