未能在IE中加载DOM: 7009错误(无法解码)的图像

When loading many images on a single page in IE (reproduced in IE11), some of them begin to fail to load, and have something similar to the following warning in the console:

当在IE中加载多个图像(在IE11中复制)时，有些图像开始无法加载，控制台中类似如下警告:

DOM7009: Unable to decode image at URL: '[some unique url]'.

DOM7009:无法解码图像的URL:“[一些唯一的URL]”。

When I look at the network traffic, there does appear to valid responses received for each of these images from the server. It's not always the same images each time. If I use the dev tools to force the image to reload (example: I update the url to include some some extraneous url parameter "&test=1"), it loads/renders normally without error. I've reproduced this behavior with different types of images (jpegs/pngs; example png included below). It seems to happen more frequently as the number of images go up, and may also have some correlation with the size of each image.

当我查看网络流量时，从服务器收到的每个图像都有有效的响应。不是每次都是相同的图像。如果我使用dev工具来强制重新加载图像(例如:我更新url以包含一些无关的url参数“&test=1”)，它就可以正常地加载/呈现。我用不同类型的图像(jpegs/pngs;下面的例子包括png)。随着图像数量的增加，这种情况似乎会更频繁地发生，并且可能与每个图像的大小有一定的相关性。

Any thoughts as to what might be causing this? Potential work-arounds? Any help is appreciated.

有什么想法可能导致这种情况吗?潜在的解决方法吗?任何帮助都是感激。

11 个解决方案

#1

It looks like the actual problem is addressed in another Stack Overflow question. All of the answers here get around the issue in various ways, but this is likely happening because the file is not the format it claims to be. Because nosniff is enabled, the browser is unable to work around this issue, and attempts to decode the wrong image type.

看起来实际的问题在另一个堆栈溢出问题中得到了解决。这里所有的答案都以不同的方式来回避这个问题，但这很可能是因为文件不是它声称的格式。由于启用了nosmell，浏览器无法解决这个问题，并试图解码错误的图像类型。

In other words: Your file extension does not match the actual encoding

换句话说:您的文件扩展名与实际的编码不匹配

#2

I had a similar problem where a file was reported in the HTTP headers as a JPEG but was in fact a PNG. Changing the filetype to match the file or removing the "X-Content-Type-Options" header fixed the problem.

我有一个类似的问题，在HTTP报头中报告一个文件作为JPEG，但实际上是PNG。更改文件类型以匹配文件或删除“X-Content-Type-Options”标题解决了问题。

#3

I had this problem in a site hosted in IIS due the X-Content-Type-Options header being set in a parent applications web.config like this:

由于在父应用程序web中设置了X-Content-Type-Options头，所以我在IIS中托管的一个站点上遇到了这个问题。配置是这样的:

<system.webServer>   
 <httpProtocol>    
  <customHeaders>    
   <add name="X-Content-Type-Options" value="nosniff" />    
  </customHeaders>    
 </httpProtocol> 
</system.webServer>  

Removing it in the applications web.config fixed it:

在应用程序web中删除它。配置固定:

<remove name="X-Content-Type-Options" />  

#4

The problem I was facing off was similar. I have a Java web application which shows pages and thumbnails of a document through Servlet requests, which responds to the browser sending PNG images. Like @user1069816 said, the responses were arriving with a header that was causing the problem "Unable to decode image":

我所面临的问题是相似的。我有一个Java web应用程序，它通过Servlet请求显示文档的页面和缩略图，该请求响应发送PNG图像的浏览器。就像@user1069816说的那样，响应以一个标题到达，导致了“无法解码图像”的问题:

X-Content-Type-Options: nosniff

In my case, this header were introduced by Spring Security. Besides this is a security mechanism for Internet Explorer to avoid XSS attacks, the fastest solution to disable this header on response were putting the following line on the application context file of Spring Security, headers section:

在我的例子中，这个头是由Spring Security引入的。除了这是Internet Explorer的一种安全机制以避免XSS攻击之外，在响应上禁用此标头的最快解决方案是在Spring security的应用程序上下文文件header中添加以下一行:

<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>

This problem were only happening on Internet Explorer 11. Not in Chrome or Firefox.

这个问题只发生在Internet Explorer 11上。不是Chrome或火狐浏览器。

#5

If it's of any use I have been seeing this on my WinJS application and I believe it's a way of renderer reporting that it's out of memory (albeit cryptically!)

如果有什么用的话，我在我的WinJS应用程序上看到过，我相信这是渲染器报告内存不足的一种方式(尽管很神秘!)

Reason I say that is that if I load an compressed png image which is say 500KB, but large in terms of pixel dimensions I get this problem.

我说的原因是如果我加载一个压缩的png图像它是500KB，但是在像素维度上我得到了这个问题。

E.g.

如。

If I try this with a 20000 x 6000 image I get this error sporadically, which I'm guessing is because it's 20000 x 6000 x 4 (480,000,000 bytes) or ~480MB.

如果我用20000 x 6000的图像做这个，我就会偶尔得到这个错误，我猜是因为它是20000 x 6000 x 4(480,000,000字节)或~480MB。

If I try this with a 14000 x 6000 it would be ~336MB which seems OK and I have yet to get the error.

如果我用14000 x 6000，它会是~336MB，看起来没问题，我还没有得到错误。

If I try this with a 35000 x 20000 image ~2.8GB it always happens.

如果我用一个35000×20000的图像~2.8GB试试这个，它总是会发生。

#6

Yes i got same issue in the IE11 when i load images it was giving me error "

是的，我在IE11中遇到了同样的问题当我加载图片时它会给我错误

• DOM7009: Unable to decode image at URL and in all other browser it work like a charm,
• DOM7009:无法在URL和所有其他浏览器中解码图像，它的工作方式就像一种魅力，

After lot of googling finally came on the conclusion as below :

经过大量的谷歌搜索，最终得出如下结论:

in the Web.config file ::

在Web。配置文件:

  <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>

Please see the commented code i have removed the "X-Content-Type-Options" and it works !!!

请查看我删除的注释代码“X-Content-Type-Options”，它就可以工作了!!

#7

I experienced this same error on a page that was essentially an image gallery, where each image was being loaded at full resolution as the thumbnail. The page weight was approx 220mb. Some of the thumbnails weren't loading, and the "unable to decode image at url" error was being given as the reason.

我在一个本质上是一个图片库的页面上遇到了同样的错误，在这个页面中，每个图片都以缩略图的完全分辨率被加载。页面重约220mb。一些缩略图没有加载，“无法在url上解码图像”的错误被给出了原因。

However, IE could load up each image individually by viewing the image's URL directly, which I think means there wasn't a problem with the image type/encoding. So while IE11 could load up the individual image, it couldn't load up all the images as thumbnails (and the images that weren't loaded changed each time the page was refreshed).

但是IE可以通过直接查看图像的URL来单独加载每个图像，我认为这意味着图像类型/编码没有问题。因此，虽然IE11可以加载单个图像，但它不能以缩略图的形式加载所有图像(而且每次刷新页面时，未加载的图像都会发生变化)。

My workaround was to display a low res thumbnail on the page (page weight changed to 220kb), and have the thumbnail link to the full, hi-res image.

我的解决方案是在页面上显示一个低分辨率的缩略图(页面重量更改为220kb)，并将缩略图链接指向完整的高分辨率图像。

It would be worth checking if you can reduce the dimensions of the images served, and also the file size.

如果您可以减少所服务的图像的尺寸，以及文件大小，那就值得检查了。

#8

I've encountered this error as well — IE 11.0.9600.18059. According to my testing, it was almost certainly due to the amount of memory consumed by the tab (eg: adding extra DOM elements increases the memory usage) — not to be confused with the amount of data loaded over the network.

我也遇到过这个错误——11.0.9600.18059。根据我的测试，这几乎肯定是由于选项卡所消耗的内存(例如:添加额外的DOM元素增加了内存使用)—不要与通过网络加载的数据量混淆。

Using the memory profiler, I found that errors occurred once memory usage hit a ceiling around 1.5GB. This caused the following weirdness:

通过使用内存分析器，我发现当内存使用量达到大约1.5GB的上限时，就会出现错误。这就产生了以下奇怪的现象:

1. Some images would be loaded, but wouldn't render. They'd show up as an empty space in the page (with the correct dimensions), as though the image had been set to visibility: hidden.
2. 有些图片会被加载，但不会渲染。它们将显示为页面中的一个空空间(具有正确的尺寸)，就好像图像被设置为可视性:hidden。
3. Some images would be loaded, but would fail to decode. They'd show up as a small black box with an X. These images would also show a DOM7009 error in the console.
4. 有些图像会被加载，但无法解码。它们会显示为一个带有x的小黑盒，这些图像还会显示控制台中的DOM7009错误。
5. Flash SWFs would show up as black boxes.
6. Flash swf会以黑匣子的形式出现。
7. Other random weirdness.
8. 其他随机的古怪。

Different images/SWFs would be affected each time I reloaded the page.

每次重载页面时，都会影响不同的图像/SWFs。

The solution for me was to simply adjust the way the page is designed, so it's not causing IE to consume as much memory.

我的解决方案是简单地调整页面的设计方式，这样就不会导致IE消耗那么多内存。

#9

I had this problem just now when the image was ~2.5MB (.jpg). Shrunk it down to 540kb and the problem no longer occurs. Looks like it's definitely an IE memory issue (or can be in some occasions).

我刚才遇到了这个问题，当时图像是~2.5MB (.jpg)。将它缩小到540kb，问题就不再发生了。看起来这绝对是IE内存问题(或者在某些情况下)。

This is the only fix that worked for me as I didn't have anything relating to X-Content-Type-Options in my web config.

这是唯一对我有用的修复，因为我的web配置中没有任何与x内容类型选项相关的内容。

#10

The only way that I found to solve this is disable this rule by browser in apache server configuration.

我发现解决这个问题的唯一方法是在apache服务器配置中禁用这个规则。

 BrowserMatch MSIE explorer
 Header set X-Content-Type-Options nosniff env=!explorer

It work for me but this solution doesnt like me. I would prefer to rewrite in apache server the correct mime-type.

这个办法对我有用，但我不喜欢这个办法。我宁愿在apache服务器中重写正确的mime类型。

My problem is that the URL contains the "captcha" string, but I can`t set it.

我的问题是URL包含“captcha”字符串，但是我不能设置它。

SetEnvIf Request_URI ^(.*)captcha$ headerpng 
Header set "Content-type image/png" env=headerpng 

This doesnt work. It's a little frustrating. It's a url so long and I thing that **SetEnvIf** doesnt read it until the end.

这并不工作。这有点令人沮丧。它的url太长了，我觉得** ** *直到最后才会读到它。

#11

I get the same issue frequently with IE11 and I can't pinpoint what is causing it. However, it starts to happens right after JavaScript has crashed. I'ts not an imgur problem, its an IE11 problem.

我经常在IE11中遇到同样的问题，我无法确定是什么导致了它。然而，它在JavaScript崩溃后立即开始发生。我不是imgur问题，而是IE11问题。

The only way that I have been able to get out of the issue is to crash explorer and reload it or reboot.

我能够摆脱这个问题的唯一方法是崩溃资源管理器并重新加载它或重新启动它。