FAQ

There were 2 different ways to send a PDF to the clients browser:

Send the file to the browser and force a file download. Or send the file inline to the browser and the plugin is used, if available. In both ways you could pass a filename, send with the response header, to the browser. The browsers theirself respect that filename and you were able to save the PDF through the browsers save function by the give filename.

That behaviour differs from the save dialog of the plugin, which displays the PDF in the browser. A plugin doesn't care about the filename send via the header - or maybee the browsers simply do not pass the name through.

Let's take following URL to start our tests:

http://www.example.com/createPdf.php

The given URL will produce a PDF file and send among others the following headers:

Content-Type: application/pdf
Content-Disposition: inline; filename="MyDynamicPdf.pdf"

If you save the file through a browsers "save page" function, the save dialog will offer you, as expected, MyDynamicPdf.pdf as the filename. If you try to save the document with the save function of the plugin the filename will looks like something like that:

http___www_example_com_createPdf.pdf

or it will be simply the name of the script that generates the file:

createPdf.pdf

As you can see the plugin uses the information from the address-bar of the browser to create the filename. Very bad, isn't? We did some tests and found a very neat trick to pass a filename to the plugin via the adress-bar.

Several people out there tried to pass the filename through a GET parameter:

http://www.example.com/createPdf.php?some=vars&/MyDynamicPdf.pdf

...which only worked with the Internet Explorer 6 and Acrobat Reader 6! But no other combination...

The following trick makes it work with nearly all browser/plugin combinations:

http://www.example.com/createPdf.php/MyDynamicPdf.pdf?some=vars

As you can see it's only the position of the filename which had changed!

If you have to pass additional GET parameters to your script, make sure that the are correctly encoded as described in RFC 1738 (urlencode or rawurlencode). This is needed because the plugin will fail on a not encoded slash.

We tested this solution on several apache webservers and it worked on all without mod_rewrite-magic. If you've experiences with other webservers, you're welcome to let us know!