<p>pdf.js s'appuie sur les URL pour contenir l'extension 'pdf'</p>

Créé le 12 févr. 2014 · 13Commentaires · Source: mozilla/pdf.js

Lorsque le serveur ne fournit pas l'en-tête Content-Disposition, pdf.js s'appuie sur les URL pour contenir l'extension 'pdf'. Mais les URL sont des localisateurs, pas des noms.
Étapes à suivre pour reproduire:

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

Cliquez maintenant sur télécharger. Un fichier «document.pdf» vous sera proposé. Le nom devrait être quelque chose de plus significatif.
Le bogue se produit également lorsque je laisse de côté l'extension pdf sur mon serveur Web Apache.

Solution proposée:
Utilisez le titre du pdf. (comme ce code viewer.js ). Le titre est également utilisé par Firefox pour la fonctionnalité Fichier -> "Enregistrer la page sous" lors de l'affichage d'une page HTML comme http://en.wikipedia.org/wiki/Internet_media_type .

Toutes les pages Web html ne se terminent pas par .html. Au lieu de cela par l'extension, le type d'un document est spécifié par son type MIME.
Cependant, la plupart des fichiers pdf ont l'extension pdf, et la plupart des fichiers PDF en ligne ont également un nom bon à stocker dans l'URL.
Je ne sais pas si la nouvelle méthode de récupération doit écraser la récupération d'url ou être une solution de secours.

Voir également # 3455.

1-core 5-good-beginner-bug

Source

octosquid

Tous les 13 commentaires

@timvandermeij

Une mise à jour pour ceci? Il est ouvert depuis plus de deux ans maintenant. Étant donné que mon paramètre de fichier est un appel de serveur qui renvoie un fichier pdf, le visualiseur de pdf ne peut pas détecter le nom du fichier car il semble rechercher une extension .pdf et je suis donc bloqué avec "document.pdf "lors du téléchargement et" untitled.pdf "dans la barre de fenêtre lors de la visualisation.

Ce serait pratique si nous pouvions également spécifier un "titre" dans l'URI ainsi que le "fichier" tel que ... / pdf-viewer / viewer.html? File = "..." & title = "... "

Mercieral le 22 août 2016

Je sais que des travaux sont actuellement en cours dans # 7554 pour prendre en charge l'en-tête Content-Disposition , ce qui est un moyen de résoudre ce problème. Cependant, je suis d'accord que document.pdf n'est pas le meilleur nom possible et que nous devrons peut-être améliorer la fonction pour obtenir le nom (fichier). Les correctifs pour cela sont les bienvenus, donc j'étiquette cela comme un bon bogue pour débutant car il ne devrait pas être trop difficile à implémenter.

timvandermeij le 23 août 2016

@timvandermeij Excellent merci, je crois que soutenir Content-Disposition résoudrait mon problème.

Je suis d'accord, en parcourant le code, j'ai remarqué qu'il ne devrait pas être trop difficile d'ajouter simplement un autre paramètre d'URL pour le nom de fichier. Je vais essayer dans les prochains jours, merci.

Mercieral le 23 août 2016

Les correctifs pour cela sont les bienvenus, donc j'étiquette cela comme un bon bogue pour débutant car il ne devrait pas être trop difficile à implémenter.

@timvandermeij Veuillez vous rappeler que dans PR # 4956, nous avons délibérément abandonné la
Je ne pense donc pas que nous devrions permettre de spécifier le title utilisant un paramètre de hachage!

D'autant que ce serait non standard (dans le contexte de http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/pdf_open_parameters.pdf), et comparé au Content-Disposition approche

Snuffleupagus le 23 août 2016

👍1

Désolé, j'aurais dû être plus clair. Je voulais dire que les correctifs sont les bienvenus pour améliorer la fonction qui détermine le nom du fichier à partir de l'URL. Je pense que nous pouvons faire mieux là-bas au lieu de nous fier uniquement à l'extension de fichier. Je conviens que nous ne devrions pas ajouter plus de paramètres de hachage.

timvandermeij le 23 août 2016

👍1

Quel est le statut de ce problème? Est-ce toujours ouvert?

anirudhrb le 1 mars 2017

Quel est le statut de ce problème? Est-ce toujours ouvert?

@anirudhrb est toujours ouvert, il y a eu une tentative d'implémentation à # 7554, souhaitez-vous y contribuer?

yurydelendik le 1 mars 2017

@yurydelendik Oui, j'aimerais contribuer. Qu'est-ce qui est attendu dans un PR pour ce problème?

anirudhrb le 1 mars 2017

@anirudhrb , vous pouvez simplement prendre le PR ci-dessus comme base car il a un peu raison de la communication à distance des données - nous nous attendrions à un petit patch avec des tests unitaires. Nous n'avons pas besoin d'analyser la spécification Content-Disposition, mais suffisamment pour obtenir le nom de fichier.

yurydelendik le 1 mars 2017

@yurydelendik J'ai commencé à travailler là-dessus. C'est ma première tentative de contribution à un projet open-source. J'aurai besoin de temps pour me familiariser avec la base de code. :)

anirudhrb le 4 mars 2017

@yurydelendik , @timvandermeij Pourrais-je aborder ce problème si cela vous

himanish-star le 2 janv. 2018

Il y a une pull request ci-dessus qui semble être la bonne direction, mais il n'y a plus eu d'activité pour cela. Si vous souhaitez réparer celui-ci, cela semble bien. Je vais demander si l'auteur original envisage toujours de travailler dessus.

timvandermeij le 2 janv. 2018

Corrigé dans # 9379.

timvandermeij le 18 janv. 2018

Cette page vous a été utile?

0 / 5 - 0 notes