pdf.js relies on urls to contain the 'pdf' extension

When the server doesn’t provide the Content-Disposition header, pdf.js relies on urls to contain the ‘pdf’ extension. But URLs are locators, not names. Steps to reproduce:

mv web/compressed.tracemonkey-pldi-09.pdf web/compressed.tracemonkey-pldi-09
sed -i 's/compressed.tracemonkey-pldi-09.pdf/compressed.tracemonkey-pldi-09/g' web/viewer.js
firefox web/viewer.html

Now click on download. You will be offered a ‘document.pdf’ file. The name should be something more meaningful. The bug also happens when I leave out the pdf extension on my apache web server.

Proposed solution: Use the title of the pdf. (as this viewer.js code). The title is also used by firefox for the File -> “save page as” functionality when displaying a HTML page like http://en.wikipedia.org/wiki/Internet_media_type .

Not every html web page ends in .html. Instead by the extension, a document’s type is specified by its MIME-type. However, most pdf files have the pdf extension, and most pdfs online also have a good-to-store name in the url. I don’t know whether the new retrieval method should overwrite the url retrieval, or be a fallback to it.

See also #3455.

[timvandermeij]

Sorry, I should have been more clear. I meant that patches are welcome for improving the function that determines the file name from the URL. I think we can do better there instead of only relying on the file extension. I agree that we should not add more hash parameters.

[Snuffleupagus]

Patches for this are welcome, so I’m labeling this as a good beginner bug as it should not be too hard to implement.

@timvandermeij Please remember that in PR #4956 we purposely moved away from letting various hash parameters affect the viewer (unless debugging is enabled, see https://github.com/mozilla/pdf.js/wiki/Debugging-pdf.js). Hence I do not think that we should make it possible to specify the title using a hash parameter!

Especially considering that it would be non-standard (in the context of http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/pdf_open_parameters.pdf), and compared to the Content-Disposition approach in PR #7554, it really doesn’t add much value.