Lors du chargement de nombreuses images sur une seule page dans IE (reproduit dans IE11), certaines d'entre elles commencent à ne pas se charger et ont un avertissement similaire à l'avertissement suivant dans la console:
DOM7009: Impossible de décoder l'image à l'URL: '[URL unique]'.
Lorsque je regarde le trafic réseau, il semble que les réponses reçues pour chacune de ces images par le serveur soient valides. Ce ne sont pas toujours les mêmes images à chaque fois. Si j'utilise les outils de développement pour forcer l'image à recharger (exemple: je mets à jour l'URL afin d'inclure des paramètres d'URL superflus "& test = 1"), il se charge/restitue normalement sans erreur. J'ai reproduit ce comportement avec différents types d'images (jpegs/pngs; exemple de png inclus ci-dessous). Cela semble se produire plus fréquemment à mesure que le nombre d'images augmente, et peut également avoir une certaine corrélation avec la taille de chaque image.
Des idées sur ce qui pourrait être la cause? Solutions de rechange potentielles? Toute aide est appréciée.
Il semble que le problème actuel soit traité dans une autre question relative au débordement de pile . Toutes les réponses ici résout le problème de différentes manières, mais cela se produit probablement car le fichier n’est pas le format qu’il prétend être. Parce que nosniff est activé, le navigateur ne peut pas résoudre ce problème et tente de décoder le type d'image incorrect.
En d'autres termes: votre extension de fichier ne correspond pas à l'encodage réel
J'ai eu un problème similaire où un fichier a été signalé dans les en-têtes HTTP en tant que JPEG mais était en fait un PNG. Changer le type de fichier pour qu'il corresponde au fichier ou supprimer l'en-tête "X-Content-Type-Options" a résolu le problème.
J'ai rencontré ce problème dans un site hébergé dans IIS en raison de l'en-tête X-Content-Type-Options défini dans un fichier Web.config d'applications parent, comme ceci:
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="X-Content-Type-Options" value="nosniff" />
</customHeaders>
</httpProtocol>
</system.webServer>
Le supprimer dans les applications web.config l'a corrigé:
<remove name="X-Content-Type-Options" />
Le problème auquel je faisais face était similaire. J'ai une application Web Java qui affiche les pages et les vignettes d'un document via des requêtes Servlet, qui répond au navigateur en envoyant des images PNG. Comme @ user1069816, les réponses arrivaient avec un en-tête à l'origine du problème "Impossible de décoder l'image":
X-Content-Type-Options: nosniff
Dans mon cas, cet en-tête a été introduit par Spring Security. En plus, c’est un mécanisme de sécurité permettant à Internet Explorer d’éviter les attaques XSS , la solution la plus rapide pour désactiver cet en-tête a été de placer la ligne suivante dans le fichier de contexte d’application de Spring Security, section headers
:
<http use-expressions="true" create-session="never" auto-config="true">
<headers>
<!-- this section disable put the header 'X-Content-Type-Options' -->
<content-type-options disabled="true"/>
</headers>
Ce problème ne se produisait que sur Internet Explorer 11. Pas dans Chrome ou Firefox.
Oui, j'ai eu le même problème dans l'IE11 lorsque j'ai chargé des images, cela me donnait une erreur "
Après beaucoup de recherches sur Google, nous en sommes venus à la conclusion ci-dessous:
dans le fichier Web.config ::
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="X-Frame-Options" value="Deny" />
<remove name="X-Powered-By" />
<add name="X-XSS-Protection" value="1" />
<!--To resolve the user image not displaying in the chat and in the header for IE 11-->
<!--<add name="X-Content-Type-Options" value="nosniff"/>-->
</customHeaders>
</httpProtocol>
</system.webServer>
S'il vous plaît voir le code commenté j'ai supprimé le " X-Content-Type-Options " et ça marche !!!
Si cela peut être utile, je vois cela sur mon application WinJS et je pense que c'est un moyen de rendre compte que la mémoire est saturée (même si c'est crypté!)
La raison pour laquelle je dis que c’est que si je charge une image png
compressée, disons 500 Ko, mais dont les dimensions en pixels sont élevées, j’obtiens ce problème.
Par exemple.
Si j'essaye cela avec une image 20000 x 6000, j'obtiens cette erreur de façon sporadique, ce qui, je suppose, est parce que c'est 20000 x 6000 x 4 (480 000 000 octets) ou ~ 480 Mo.
Si j'essaye cela avec un 14000 x 6000, ce serait ~ 336Mo, ce qui semble bien et je n'ai pas encore eu l'erreur.
Si j'essaie cela avec une image de 35 000 x 20 000, environ 2,8 Go, cela se produit toujours.
J'ai aussi rencontré cette erreur - IE 11.0.9600.18059. Selon mes tests, cela était certainement dû à la quantité de mémoire consommée par l'onglet (par exemple: l'ajout d'éléments DOM supplémentaires augmente l'utilisation de la mémoire) - à ne pas confondre avec la quantité de données chargées sur le réseau.
À l'aide du profileur de mémoire, j'ai constaté que des erreurs se produisaient une fois l'utilisation de la mémoire plafonnée à environ 1,5 Go. Cela a causé l'étrangeté suivante:
visibility: hidden
.Différentes images/fichiers SWF seraient affectés chaque fois que je rechargerais la page.
La solution pour moi était simplement d’adapter la conception de la page, de manière à éviter que IE consomme autant de mémoire.
J'ai eu ce problème tout à l'heure quand l'image était ~ 2.5MB (.jpg). Réduisez-le à 540 Ko et le problème ne se pose plus. On dirait que c'est définitivement un problème de mémoire IE (ou peut l'être à certaines occasions).
C’est le seul correctif qui a fonctionné pour moi car je n’avais aucun élément relatif à X-Content-Type-Options
dans ma configuration Web.
J'ai rencontré cette même erreur sur une page qui était essentiellement une galerie d'images, dans laquelle chaque image était chargée à pleine résolution en tant que vignette. Le poids de la page était d'environ 220 mb. Certaines des vignettes n'étaient pas en cours de chargement et l'erreur "incapable de décoder l'image à l'URL" était indiquée.
Cependant, IE peut charger chaque image individuellement en affichant directement l'URL de l'image, ce qui signifie que le type/encodage de l'image ne posait pas de problème. Ainsi, alors qu'IE11 pouvait charger une image individuelle, il ne pouvait pas charger toutes les images sous forme de vignettes (et les images non chargées étaient modifiées à chaque fois que la page était rafraîchie).
Ma solution de contournement consistait à afficher une vignette basse résolution sur la page (le poids de la page avait été modifié à 220 Ko) et à faire en sorte que la vignette soit liée à l'image complète en haute résolution.
Il serait intéressant de vérifier si vous pouvez réduire les dimensions des images servies, ainsi que la taille du fichier.
La seule façon pour moi de résoudre ce problème consiste à désactiver cette règle par navigateur dans la configuration du serveur Apache.
BrowserMatch MSIE Explorer
Header set X-Content-Type-Options nosniff env=!Explorer
Cela fonctionne pour moi mais cette solution ne m'aime pas. Je préférerais réécrire sur le serveur Apache le type de mime correct.
Mon problème est que l'URL contient la chaîne "captcha", mais je ne peux pas la définir.
SetEnvIf Request_URI ^(.*)captcha$ headerpng
Header set "Content-type image/png" env=headerpng
Cela ne__t work. It's a little frustrating. It's a url so long and I thing that **SetEnvIf** doesn
t le lire jusqu'à la fin.
Je rencontre fréquemment le même problème avec IE11 et je ne parviens pas à identifier sa cause. Cependant, cela commence à se produire juste après le crash de JavaScript. Ce n'est pas un problème imgur, c'est un problème IE11.
La seule façon pour moi de sortir de ce problème est de planter Explorer, de le recharger ou de le redémarrer.