Ressource interprétée comme Document mais transférée avec une application / zip de type MIME

Avec Chrome 12.0.742.112, si je redirige avec les en-têtes suivants:

HTTP/1.1 302 Found 
Location: http://0.0.0.0:3000/files/download.zip
Content-Type: text/html; charset=utf-8
Cache-Control: no-cache
X-Ua-Compatible: IE=Edge
X-Runtime: 0.157964
Content-Length: 0
Server: WEBrick/1.3.1 (Ruby/1.9.2/2011-02-18)
Date: Tue, 05 Jul 2011 18:42:25 GMT
Connection: Keep-Alive

Le cas échéant, renvoie l'en-tête suivant:

HTTP/1.1 200 OK 
Last-Modified: Tue, 05 Jul 2011 18:18:30 GMT
Content-Type: application/zip
Content-Length: 150014
Server: WEBrick/1.3.1 (Ruby/1.9.2/2011-02-18)
Date: Tue, 05 Jul 2011 18:44:47 GMT
Connection: Keep-Alive

Chrome ne redirigera pas et ne modifiera pas la page précédente, il ne fera que signaler l'avertissement suivant dans la console:

Ressource interprétée comme Document mais transférée avec une application / zip de type MIME.

Le processus fonctionne correctement dans Firefox, et fonctionne également très bien dans Chrome si j'ouvre un nouvel onglet et que je vais directement sur http://0.0.0.0:3000/files/download.zip. Suis-je en train de faire quelque chose de mal, ou est-ce un bug / bizarrerie de Chrome?

Vous pouvez spécifier l' attribut de téléchargement HTML5 dans votre balise <a>.

<a href="http://example.com/archive.zip" download>Export</a>

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#attr-download

Dans votre en-tête de demande, vous avez envoyé Content-Type: text/htmlce qui signifie que vous souhaitez interpréter la réponse en HTML. Maintenant, même si le serveur vous envoie des fichiers PDF, votre navigateur essaie de le comprendre en HTML. C'est le problème. J'essaie de voir quelle pourrait être la raison. :)

J'ai rencontré ce problème lors de la diffusion d'un fichier PDF (application de type MIME / pdf) et je l'ai résolu en définissant l'en-tête Content-Disposition, par exemple:

Content-Disposition: attachment; filename=foo.pdf

J'espère que cela pourra aider.

J'ai corrigé cela… en ouvrant simplement un nouvel onglet.

Pourquoi cela ne fonctionnait pas, je ne suis pas tout à fait sûr, mais cela pourrait avoir quelque chose à voir avec la façon dont Chrome traite les téléchargements multiples sur une page, peut-être qu'il pensait qu'il s'agissait de spam et les avait simplement ignorés.

Je ne pouvais trouver nulle part une explication du message en soi. Voici mon interprétation.

Autant que je sache, Chrome s'attendait à du matériel qu'il pourrait éventuellement afficher (un document ), mais il a obtenu quelque chose qu'il ne pouvait pas afficher (ou quelque chose qu'on lui avait dit de ne pas afficher).

Il s'agit à la fois de savoir comment le document a été déclaré au niveau de la page HTML dans href(voir l' downloadattribut dans le message de Roy) et comment il est déclaré dans la réponse du serveur au moyen d'en-têtes HTTP (notamment Content-Disposition). C'est une question de contrat , par opposition à l'espoir et à l'attente.

Pour continuer sur le chemin d'Evan, j'ai vécu cela:

Content-type: application/pdf
Content-disposition: attachment; filename=some.pdf

est tout simplement incompatible avec:

<a href='some.pdf'>

Chrome va pleurer Ressource interprétée comme document mais transférée…

En fait, la disposition des pièces jointes signifie simplement ceci: le navigateur ne doit pas interpréter le lien, mais plutôt le stocker quelque part à d'autres fins — cachées —. Ci-dessus, soit il downloadmanque à côté href, soit il Content-dispositiondoit être supprimé des en-têtes. Cela dépend si nous voulons que le navigateur rende le document ou non.

J'espère que cela t'aides.

J'ai rencontré ce même problème aujourd'hui avec Chrome Version 30.0.1599.66 avec mon application node.js / express.js.

Les en-têtes sont corrects, express les définit correctement automatiquement, cela fonctionne dans les autres navigateurs comme indiqué, en mettant l'attribut de téléchargement html 5 ne résout pas, ce qui l' a résolu va dans les paramètres avancés de chrome et en cochant la case "Demander où enregistrer chaque fichier avant le téléchargement ".

Après cela, aucune erreur "Ressource interprétée comme document ...." n'a été signalée comme dans le titre de ce problème, il semble donc que notre code de serveur soit correct, c'est Chrome qui signale incorrectement cette erreur dans la console lorsqu'il est configuré pour enregistrer. fichiers vers un emplacement automatiquement.

J'ai eu un problème similaire lors d'un téléchargement de fichier via Javascript. L'ajout de l'attribut de téléchargement n'a fait aucune différence, mais l'ajout de target = '_ blank' l'a fait - je ne reçois plus le message de la console 'Ressource interprétée comme document ...'.

Voici mon code très simple:

var link = document.createElement('a');
link.target = '_blank';
link.href = url;
document.body.appendChild(link); // Required for Firefox
link.click();
link.remove(); 

Je ne l'ai pas essayé avec du HTML direct mais je m'attendrais à ce qu'il fonctionne.

Notez que j'ai découvert que Firefox nécessite que le lien soit ajouté au document tandis que Chrome fonctionnera sans lui.

Je l'ai rencontré lorsque j'ai attribué src = "image_url" dans un iframe. Il semble que iframe l'interprète comme un document, mais ce n'est pas le cas. C'est pourquoi il affiche un avertissement.

J'ai résolu le problème par adding target="_blank"le lien. Avec cela, Chrome ouvre un nouvel onglet et charge le PDF sans avertissement, même en mode réactif.

J'ai eu ce problème dans un projet de site Web ASP. L'ajout d'un en-tête "Content-Length" a entraîné le redémarrage des téléchargements dans Chrome.

Ce problème est réapparu dans la version Chrome 61. Mais il semble qu'il soit corrigé sur Chrome 62.

J'ai une règle de réécriture comme ci-dessous

RewriteRule ^/ShowGuide/?$ https://<website>/help.pdf [L,NC,R,QSA]

Avec Chrome 61, le PDF ne s'ouvrait pas, dans la console il montrait le message

"Resource interpreted as Document but transferred with MIME type application/pdf: "

Nous avons essayé d'ajouter le type MIME dans la règle de réécriture comme ci-dessous, mais cela n'a pas aidé.

RewriteRule ^/ShowGuide/?$ https://<website>/help.pdf [L,NC,R,QSA, t:application/pdf]

J'ai mis à jour mon Chrome vers la dernière version 62 et il a recommencé à afficher le PDF. Mais le message est toujours là dans la console.

Avec tous les autres navigateurs, cela fonctionnait / fonctionne bien.

Je suis juste tombé sur cela et aucune des autres informations que j'ai pu trouver n'a aidé: c'était une erreur stupide: j'envoyais la sortie au navigateur avant de commencer le téléchargement du fichier. Étonnamment, je n'ai trouvé aucune erreur utile trouvée (comme "en-têtes déjà envoyés", etc.). Avec un peu de chance, cela sauve quelqu'un d'autre de chagrin!

Dans mon cas, le nom de fichier était trop long et a obtenu la même erreur. Une fois raccourci en dessous de 200 caractères, il fonctionnait bien. (la limite pourrait être de 250?)

J'ai eu cette erreur car je servais depuis mon système de fichiers. Une fois que j'ai commencé avec un serveur http, chrome pouvait le comprendre.

Je rencontrais le même problème avec un gestionnaire de téléchargement que j'ai créé. Le problème que j'avais dû impliquer le nom de fichier étant trop long et l'extension coupée.

Exemple: nom de fichier: protocoles d'organisation et autres éléments importants.pd

<?php
  header("Content-Disposition: attachment; filename=$File_Name");
?>

Solution: augmentation du champ de base de données MySQL à 255 pour stocker le nom de fichier et vérification de la longueur avant d'enregistrer le blob. Si la longueur> 255, réduisez-la à 250 et ajoutez l'extension de fichier.

Essayez le code ci-dessous et j'espère que cela fonctionnera pour vous.

var Interval = setInterval(function () {
                if (ReportViewer) {
                    ReportViewer.prototype.PrintReport = function () {
                        switch (this.defaultPrintFormat) {
                            case "Default":
                                this.DefaultPrint();
                                break;
                            case "PDF":
                                this.PrintAs("PDF");
                                previewFrame = document.getElementById(this.previewFrameID);
                                previewFrame.onload = function () { previewFrame.contentDocument.execCommand("print", true, null); }
                                break;
                        }
                    };
                    clearInterval(Interval);
                }
            }, 1000);

J'ai fait face à cela aujourd'hui, et mon problème était que mon Content-Dispositiontag a été mal réglé. Il ressemble aux deux pdf& application/x-zip-compressed, vous êtes censé le régler à la inlineplace de attachment.

Donc, pour définir votre en-tête, le code Java ressemblerait à ceci:

...
String fileName = "myFileName.zip";
String contentDisposition = "attachment";
if ("application/pdf".equals(contentType)
    || "application/x-zip-compressed".equals(contentType)) {
    contentDisposition = "inline";
}
response.addHeader("Content-Disposition", contentDisposition + "; filename=\"" + fileName + "\"");
...