Изображения, не загружаемые в IE с DOM: ошибка 7009 (неспособная декодировать) в консоли

При загрузке многих изображений на одной странице в IE (воспроизводится в IE11) некоторые из них начинают не загружаться и имеют что-то похожее на следующее предупреждение в консоли:

DOM7009: невозможно декодировать изображение по URL-адресу: "[уникальный URL-адрес]".

Когда я смотрю на сетевой трафик, появляются действительные ответы, полученные для каждого из этих изображений с сервера. Это не всегда одно и то же изображение. Если я использую инструменты dev для принудительного перезагрузки образа (например: я обновляю url, чтобы включить некоторый внешний параметр url "& test = 1" ), он загружает/визуализирует нормально без ошибок. Я воспроизвел это поведение с различными типами изображений (jpegs/pngs, пример png, приведенный ниже). Это, как представляется, происходит чаще, так как количество изображений увеличивается, а также может иметь некоторую корреляцию с размером каждого изображения.

Любые мысли о том, что может быть причиной этого? Потенциальные проблемы? Любая помощь приветствуется.

Ответ 1

Похоже, проблема актуальна в еще одном вопросе. Все ответы здесь затрагивают проблему различными способами, но это, вероятно, происходит потому, что файл не соответствует формату. Поскольку nosniff включен, браузер не может обойти эту проблему и пытается декодировать неправильный тип изображения.

Другими словами: расширение вашего файла не соответствует фактической кодировке

Ответ 2

У меня была эта проблема на сайте, размещенном в IIS, поскольку заголовок X-Content-Type-Options был установлен в родительских приложениях web.config следующим образом:

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

Удаление в приложениях web.config исправлено:

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

Ответ 3

У меня была аналогичная проблема, когда файл был указан в заголовках HTTP как JPEG, но был фактически PNG. Исправлена проблема с изменением типа файла в соответствии с файлом или удалением заголовка "X-Content-Type-Options".

Ответ 4

Проблема, с которой я столкнулся, была похожей. У меня есть веб-приложение на Java, которое показывает страницы и эскизы документа через запросы сервлетов, которые отвечают браузеру, отправляющему изображения PNG. Как сказал @user1069816, ответы приходили с заголовком, который вызывал проблему "Невозможно декодировать изображение":

X-Content-Type-Options: nosniff

В моем случае этот заголовок был представлен Spring Security. Кроме того, это механизм безопасности для Internet Explorer, позволяющий избежать XSS-атак. Самое быстрое решение для отключения этого заголовка при ответе заключалось в том, чтобы поместить следующую строку в файл контекста приложения Spring Security, раздел 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>

Эта проблема возникала только в Internet Explorer 11. Не в Chrome или Firefox.

Ответ 5

Если это было какое-либо использование, я видел это в своем приложении WinJS, и я считаю, что это способ рендеринга отчетов о том, что он не в памяти (хотя и критически!)

Причина. Я говорю, что если я загружаю сжатое png изображение, скажем, 500 КБ, но большое с точки зрения размеров пикселей, я получаю эту проблему.

Например

Если я попробую сделать это с изображением 20000 x 6000, я получаю эту ошибку спорадически, что я предполагаю, потому что это 20000 x 6000 x 4 (480 000 000 байт) или ~ 480 МБ.

Если я попробую сделать это с 14000 x 6000, это будет ~ 336 МБ, что кажется ОК, и я еще не получил ошибку.

Если я попробую сделать это с размером 35000 x 20000 ~ 2.8 ГБ, это всегда произойдет.

Ответ 6

Я тоже столкнулся с этой ошибкой - IE 11.0.9600.18059. Согласно моим испытаниям, это было почти наверняка из-за объема памяти, потребляемой вкладкой (например: добавление дополнительных элементов DOM увеличивает использование памяти) - не путать с объемом данных, загружаемых по сети.

Используя профилировщик памяти, я обнаружил, что ошибки возникли, когда использование памяти достигло потолка около 1,5 ГБ. Это вызвало следующую странность:

Некоторые изображения будут загружены, но не будут отображаться. Они отображались как пустое место на странице (с правильными размерами), как если бы изображение было установлено на visibility: hidden.
Некоторые изображения будут загружены, но не будут декодироваться. Они появятся как маленький черный ящик с X. Эти изображения также отображают ошибку DOM7009 в консоли.
Flash SWF будут отображаться как черные ящики.
Другая случайная странность.

Различные изображения /SWF будут влиять каждый раз, когда я перезагружаю страницу.

Решение для меня состояло в том, чтобы просто настроить способ создания страницы, чтобы она не вызывала у IE столько памяти.

Ответ 7

У меня та же проблема в IE11, когда я загружал изображения, это выдает мне ошибку:

DOM7009: Unable to decode image at URL

Во всех других браузерах это работает как шарм!

После небольшого исследования наконец пришли к выводу, как показано ниже:

в файле 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>

Пожалуйста, посмотрите закомментированный код, я удалил " X-Content-Type-Options ", и он работает !!!

Ответ 8

Я испытал эту же ошибку на странице, которая была по существу галереей изображений, где каждое изображение загружалось с полным разрешением в виде миниатюры. Вес страницы составлял около 220 мб. Некоторые миниатюры не загружались, и причиной была причина ошибки "неспособность декодировать изображение при URL".

Тем не менее, IE может загружать каждое изображение отдельно, напрямую просматривая URL-адрес изображения, что, я думаю, не представляет проблемы с типом/кодировкой изображения. Таким образом, хотя IE11 может загружать отдельные изображения, он не мог загружать все изображения в виде эскизов (а изображения, которые не были загружены, менялись каждый раз, когда страница обновлялась).

Мое обходное решение состояло в том, чтобы отображать миниатюру с низким разрешением на странице (вес страницы изменен на 220 кб) и иметь ссылку эскиза для полного изображения привет-Res.

Стоит проверить, можно ли уменьшить размеры обслуживаемых изображений, а также размер файла.

Ответ 9

У меня была эта проблема только сейчас, когда изображение было ~ 2,5 МБ (.jpg). Сократите его до 540 КБ, и проблема больше не возникает. Похоже, это определенно проблема с памятью IE (или может быть в некоторых случаях).

Это единственное исправление, которое сработало для меня, поскольку у меня не было ничего, связанного с X-Content-Type-Options в моей веб-конфигурации.

Ответ 10

Единственный способ решить эту проблему - отключить это правило браузером в конфигурации сервера Apache.

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

Это работает для меня, но это решение мне не нравится. Я бы предпочел переписать на сервере Apache правильный тип mime.

Моя проблема заключается в том, что URL-адрес содержит строку "captcha", но я не могу ее установить.

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

Это doesn t work. It a little frustrating. It a url so long and I thing that **SetEnvIf** doesn t читает его до конца.

Ответ 11

Я часто получаю ту же проблему с IE11, и я не могу определить, что ее вызывает. Однако это начинает происходить сразу после того, как JavaScript разбился. Я не проблема imgur, проблема IE11.

Единственный способ, которым я смог избавиться от проблемы, - это прорвать проводник и перезагрузить его или перезагрузить.