Internet explorer 8 xdomainrequest


Почему XDomainRequest не работает в IE8 или IE9

Ниже приводится XDomainRequest выполняется из JavaScript в PHP Backend на Nginx на другой подобласти. Возвращаемый результат всегда выполняет функцию ошибки, и XDomainRequest не дает отладочные данные. Есть ли что — то не так с кодом?

PHP с Предполетным Параметры Check

Я получил кросс подобласти звонков работать в любом другом браузере. Есть ли что — то особенное для IE8 и IE9, как специальное Allow-Headers или что — то еще мне не хватает?

CORS с jQuery и XDomainRequest в IE8 / 9

обновление: я настоятельно рекомендую не инвестировать какое-либо время в XDomainRequest, потому что это ужасно плохая реализация со многими ограничениями. Это в основном работает только для запросов GET на серверы без ssl, поэтому вы можете также использовать jsonp или что-то еще.

Я использую CORS для вызова кросс-доменного API, однако Internet Explorer дает проблемы. CORS должен быть возможен в IE8 и IE9 через

3 ответа:

метод POST поддерживается, и чтобы сделать междоменный https:// запрос, ваша вызывающая страница также должна быть загружена по https. Это лучшая статья, которую я нашел, которая подробно объясняет эти и другие ограничения XDomainRequest:

Я написал прокси, который будет изящно понижаться до проксирования, если используется IE9 или меньше. Вам не нужно менять свой код вообще, если вы используете ASP.NET.

решение состоит из двух частей. Первый-это скрипт jquery, который подключается к обработке jQuery ajax. Он автоматически вызовет веб-сервер, если запрос crossDomain сделан и браузер IE:

на вашем веб-сервере вы должны получить запрос, получить значение от X-CorsProxy-Url HTTP-заголовок и выполните HTTP-запрос и, наконец, верните результат.

Как отправить кросс-доменный запрос в IE8?

Всем привет!
Необходимо отправлять кросс-доменный запрос из разных браузеров. В фаерфорксе и Хроме пашет, в IE11 — тоже пашет, а вот в IE8 не пашет.
Пример кода:

И вот в этой строке в IE8 вылазит ошибка — xhr.open(«POST», ‘mysite.ru’, true); ошибка — отказано в доступе.
Возможно это связано с особенностями версии, не знаю, погуглил и не смог найти ответа.
В крадце отправляю кросс-доменный запрос с сайта А на сайт Б, в браузерах — Хром,Фаерфокс и IE11 работает норм. В некоторых более старый версиях IE ошибка. Как победить эту проблему ? Вариант отправлять с помощью Jquery не предлагать, я использую чистый JS и ради отправки запросов использовать либу — не вариант.


  • Вопрос задан более трёх лет назад
  • 444 просмотра

Во первых, проверьте, отдаёт-ли веб-сервер конечного сайта заголовок

Подробнее можно изучить здесь.

Во вторых, если обращение идет не на https, то IE8 будет выдавать предупреждающее окно.
Если в нем выбрать «Нет», то выбор запоминается на время сессии, и будет ошибка доступа.

В IE9- используется XDomainRequest, который представляет собой урезанный XMLHttpRequest.
На него действуют ограничения:

  • Протокол нужно сохранять: запросы допустимы с HTTP на HTTP, с HTTPS на HTTPS. Другие протоколы запрещены.
  • Метод open(method, url) имеет только два параметра. Он всегда асинхронный.
  • Недоступны методы, кроме GET или POST.
  • Нельзя добавлять свои заголовки, даже нельзя указать свой Content-Type для запроса, он всегда text/plain.
  • Нельзя включить передачу кук и данных HTTP-авторизации.
  • В IE8 в режиме просмотра InPrivate кросс-доменные запросы не работают.

Подробнее можно почитать здесь

Internet Explorer 8 для разработчиков

В предыдущей статье данного цикла, посвященного ключевым возможностям Internet Explorer 8, предназначенным для веб-разработчиков, рассматривались вопросы поддержки веб-стандартов и обеспечения совместимости. В настоящей статье речь пойдет об ускорении и упрощении разработки приложений для Internet Explorer 8. Как мы отметили в предыдущей статье, одним из трех основных приоритетов для поддержки разработки веб-приложений и сайтов является упрощение и ускорение разработки. К такой поддержке относятся в первую очередь встроенные средства для разработки, тестирования и отладки веб-приложений и сайтов, а также улучшения в поддержке ключевых стандартов — HTML 4.01, CSS 2.1, расширения в модели DOM, дополнительные возможности в поддержке технологии Ajax, JSON и т.п. Все это сделало Internet Explorer 8 не только быстрым, удобным в работе и совместимым с различными веб-сайтами браузером, но и полноценной платформой для широкого класса веб-разработчиков, создающих различные онлайновые решения на основе современных технологий.

Встроенные средства разработки

В предыдущей версии Internet Explorer разработчики могли установить бесплатный дополнительный компонент — Developer Toolbar, который многие применяли в качестве средства для тестирования, отладки, профилирования и даже быстрого создания прототипов веб-страниц. Из-за того что Developer Toolbar поставлялся в виде расширения, производительность этого компонента была довольно низкой, а для работы требовался большой объем памяти.

В Internet Explorer 8 компонент Developer Toolbar заменен на интегрированный набор средств разработки, которые доступны по нажатию клавиши F12 или по команде Tools > Developer Tools. Так как средства для разработки интегрированы в браузер, они более производительны, не требуют дополнительной памяти и позволяют, не покидая браузера, выполнять основные задачи по тестированию, отладке и профилированию широкого спектра веб-сайтов и веб-приложений.

К основным возможностям, предоставляемым интегрированными средствами разработки, можно отнести следующие:

  • редактирование и отладка HTML и CSS;
  • тестирование и отладка сценариев;
  • профилирование сценариев;
  • просмотр или изменение DOM-модели.


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

Встроенные в Internet Explorer 8 средства разработки

Встроенные в Internet Explorer 8 средства разработки также позволяют переключаться между различными режимами отображения — Internet Explorer 7, Internet Explorer 8, Internet Explorer 8 Compatibility View и режимами документов — Quirks, Internet Explorer 7 Standards и Internet Explorer 8 Standards. Таким образом, разработчики могут наглядным образом вносить изменения в код сайтов для обеспечения поддержки как самых последних, так и предыдущих версий браузера.

Также отметим, что встроенные в Internet Explorer 8 средства разработки могут служить хорошим инструментом для изучения опыта других разработчиков в решении различных задач — от дизайна веб-страниц до создания динамического содержимого средствами клиентских технологий.

Подробнее о встроенных средствах разработки можно прочесть на сайте MSDN:

Поддержка стандарта CSS 2.1

Как мы отметили во введении, Internet Explorer 8 полностью поддерживает стандарт Cascade Style Sheets (CSS) 2.1, описанный в спецификации World Wide Web Consorcium (W3C) Candidate Recommendation (от 17/07/2007). До появления CSS стили задавались непосредственно на уровне языка HTML, что вызывало определенные неудобства, особенно когда требовалось изменение всего стиля веб-страницы или веб-сайта. Поддержка CSS обеспечивает разработчикам и дизайнерам возможность добавлять стили (шрифтов, цветов, отступов, позиций и т.п.) ко всем элементам веб-документов и таким образом отделять данные от представления, что позволяет улучшить организацию страниц и повысить управляемость их содержимым.

Илон Маск рекомендует:  Свойство flex-basis auto

Подробнее о поддержке CSS в Internet Explorer 8 можно прочесть на сайте MSDN по адресу: http://go.microsoft.com/fwlink/?Link >

Поддержка тестов Acid2

В процессе разработки соответствие Internet Explorer 8 новейшим стандартам HTML и CSS проверялось с помощью теста Web Standards Project Acid2. В процессе тестирования было обнаружено множество ошибок в самих тестах, которые были исправлены: Microsoft предоставила World Wide Web Consorcium более тысячи тестовых сценариев, которые в настоящее время используются веб-разработчиками и компаниями, создающими веб-браузеры для обеспечения совместимости с новейшими стандартами.

Улучшения в поддержке HTML и DOM

В языке HTML используются элементы, описывающие структуру и содержание документа. Для обеспечения полного доступа к элементам, описанным в стандарте HTML 4.01, Internet Explorer 8 содержит улучшения в поддержке языка HTML. К таким улучшениям, в частности, относятся поддержка цитат с помощью элемента Q, и объект object, который теперь может представлять собой любой элемент, включая графические изображения. Помимо этого на уровне Document Object Model (DOM) улучшена поддержка атрибутов — теперь она соответствует возможностям, реализованным в других браузерах.

Более подробно об улучшениях в поддержке HTML и DOM см. на сайте по адресу: http://go.microsoft.com/fwlink/?Link >

Поддержка DOM Prototypes


Язык JavaScript — основной язык для написания сценариев в веб, чаще всего использующийся для расширения возможностей HTML и CSS, реализации дополнительной функциональности, создания веб-страниц с динамическим содержимым, а также для обеспечения совместимости веб-страниц с различными браузерами. В Internet Explorer 8 входит набор расширений JavaScript и DOM, называемый DOM Prototypes. Новые методы в языке JavaScript, называемые accessors (getter/setter), позволяют разработчикам создавать динамические свойства, которые могут выполнять код при обращении или изменении их значений. Иерархия DOM-прототипов задает все свойства как встроенные accessor-методы — веб-разработчики могут изменять встроенные методы для изменения поведения DOM-модели.

Более подробно о DOM-прототипах см. на сайте по следующим адресам: http://go.microsoft.com/fwlink/?Link >

Поддержка Ajax Navigation

Одно из основных преимуществ использования технологии Ajax — это возможность обновления содержимого страниц без традиционной навигации. В ряде сценариев это может вызывать сложности, так как адресная строка (Address Bar), кнопки Back и Forward, а также история навигации (browser history, travelog) обновляются только при традиционной навигации. В результате обновленное с помощью Ajax содержимое страницы не сохраняется в истории навигации, соответствующие компоненты браузера не обновляются и т.п. Некоторые разработчики обходят это ограничение через применение скрытого элемента IFRAME, продолжая обновлять содержимое веб-страниц с помощью Ajax. Такой подход в ряде случаев может привести к задержкам и другим негативным эффектам, влияющим на отображение содержимого веб-страниц. С помощью нового свойства, появившегося в Internet Explorer 8, — window.location.hash — содержимое адресной строки, элементов браузера и истории навигации может обновляться как и при традиционной навигации, а в коде изменение адреса можно обрабатывать по событию window.onhashchanged.

Более подробно о Ajax Navigation см. на сайте по адресу: http://go.microsoft.com/fwlink/?Link >

Поддержка DOM Storage

В настоящее время веб-страницы используют свойство document.cookie для хранения данных на локальном компьютере. С помощью cookie можно сохранять до 50 пар «ключ/значение» для одного домена, а для обработки сохраненных данных требуется анализ всей строки cookie. Описанный в спецификации HTML 5 объект DOM Storage позволяет решить задачу сохранения данных более простым способом — как на глобальном, доступном для всех сессий, так и на сессионном уровне. Объем хранилища составляет 10 Мбайт для каждого домена.

Более подробно о DOM Storage см. на сайте по адресу: http://go.microsoft.com/fwlink/?Link >

Поддержка Connection Events

Согласно спецификации HTML 5, Connection Events позволяют проверять, подключен пользователь к сети или нет. Такие события могут быть полезны при создании динамических сайтов, поскольку позволяют реагировать на изменения в сетевых соединениях. Например, если по каким-то причинам сетевое соединение было потеряно, веб-приложение может использовать локальное хранилище данных и уведомить пользователя о невозможности соединения с сетевыми ресурсами. При восстановлении сетевого соединения приложение может обновить данные в сетевом хранилище. События Connection Events создаются элементом BODY, и состояние соединения может быть проверено из сценария на JavaScript.

Более подробно о Connection Events см. на сайте по адресу: http://go.microsoft.com/fwlink/?Link >

Cross-domain Requests (XDR)

Кросс-доменные коммуникации являются ключевым механизмом технологии Ajax и лежат в основе создания составных приложений (mashups). Выполнение кросс-доменных запросов не всегда является простой задачей — это связано с тем, что многие браузеры предохраняют пользователей от кросс-сайтовых атак (cross-site attacks).

Применяя объект XDomainRequest, появившийся в Internet Explorer 8, разработчики могут выполнять кросс-доменные запросы без необходимости в выполнении запросов «сервер-сервер». Кросс-доменные запросы требуют совместного согласия (consent) между веб-страницей и сервером. Для начала кросс-доменного запроса из веб-страницы нужно создать объект XDomainRequest внутри объекта window и открыть соединение с требуемым доменом. Браузер запросит данные у соответствующего сервера и пошлет специальный HTTP-заголовок Origin с указанием источника запроса. Соединение будет завершено только в том случае, если сервер вернет заголовок Access-Control-Allow-Origin:*. Такой обмен заголовками описан в предварительной версии спецификации W3C.

Более подробно о кросс-доменных запросах см. на сайте по адресу: http://go.microsoft.com/fwlink/?Link >


Вопросы обеспечения безопасности при кросс-доменных запросах описаны по адресу: http://go.microsoft.com/fwlink/?Link >

Cross-document Messaging (XDM)

В Internet Explorer 8 кросс-доменный обмен сообщениями построен на использовании метода window.postMessage(), который позволяет различным доменам коммуницировать между собой в рамках установленного совместного согласия. Применение этой возможности может гарантировать безопасность составных приложений — кросс-доменные коммуникации предоставляют более простой и эффективный способ двунаправленных коммуникаций по сравнению с элементами IFRAME или выполнением сценариев, полученных из других доменов.

Составные приложения (Mashups) и безопасность

Новый метод объекта window — toStaticHTML() — позволяет удалить из состава страницы, адрес которой указан при вызове этого метода, все исполняемые сценарии — эта функция базируется на тех же технологиях, что и серверная библиотека Microsoft Anti Cross-Site Scripting Library.

Сериализация объектов на базе JSON (JavaScript Object Notation) часто используется для обмена данными между отдельными компонентами составных приложений. К сожалению, многие составные приложения некорректно используют JSON, полагаясь на то, что метод eval(), присутствующий в языке JavaScript, превратит сериализованные строки обратно в объекты JavaScript. Такой подход может нанести серьезный ущерб безопасности, поскольку для воссоздания объектов описанным выше способом требуется выполнение сценариев, полученных из различных доменов. Ряд методов, описанных в спецификации ECMAScript 3.1, в частности метод JSON.stringify(), позволяют превратить объект в JSON-строку, а метод JSON.parse() — выполнить обратные действия. Если результирующий объект содержит строки, которые могут воздейстовавать на DOM веб-страницы, использование описанного выше метода toStaticHTML() может предотвратить внедрение вредоносного кода.

Поддержка Data URI

Data URI позволяет вставлять в веб-страницы внешние ресурсы — например CSS-файлы или графические изображения в виде двоичных объектов — такие объекты представляются в виде строк, могут быть сохранены в локальном хранилище и позже извлечены без необходимости в обращении к сетевым ресурсам. Размер внешних ресурсов не должен превышать 32 Кбайт и ссылки на Data URI не должны применяться в качестве источников для элементов FRAME, IFRAME или SCRIPT.

Более подробно про Data URI см. описание протокола Data на сайте по адресу: http://go.microsoft.com/fwlink/?Link >

Улучшенная поддержка пространств имен

В предыдущих версиях Internet Explorer была реализована ограниченная поддержка пространств имен для компонентов — это было сделано для того, чтобы компоненты не обрабатывались как стандартные HTML-элементы. С помощью пространств имен разработчики могли изменять поведение компонентов через специальные расширения разметки — HTML Components (HTC), а разработчики, использующие технологию COM, — создавать двоичные компоненты в виде ActiveX. Только компоненты с заданными пространствами имен могли изменять свое поведение через бинарные компоненты.

Илон Маск рекомендует:  Что такое код ccvs_auth

Поддержка пространств имен в Internet Explorer 8 существенно улучшена: теперь требуется меньше кода создания экземпляра бинарного компонента и его применения — после установки соответствующего обработчика простанства имен обработчики могут вызываться из кода и использоваться для изменения поведения компонентов.

Более подробно об улучшениях в поддержке пространств имен см. на сайте по адресу: http://go.microsoft.com/fwlink/?Link >

Изменения в поддержке MIME-типов

Каждый тип файла, получаемого с веб-сервера, имеет определенный тип содержимого, называемый MIME-типом, который описывает содержимое файла: графическое изображение, текст, приложение и т.п. Для обеспечения совместимости в Internet Explorer 8 реализована возможность определения содержимого загружаемых файлов (MIME Sniffer) — в ряде случаев Internet Explorer указывает «правильный» тип файла по сравнению с тем, что описан на сервере. Например, если Internet Explorer обнаружит HTML-содержимое в файле, описанном в HTTP-заголовке как Content-Type: text/plain, Internet Explorer обработает его как HTML-файл. Поскольку существует большое число веб-серверов предыдущих версий, которые описывают все файлы как text/plain, определение содержимого файла является важной частью обеспечения совместимости браузера с различными веб-сайтами.

К сожалению, автоматическое определение содержимого файла может привести к нарушениям безопасности, поэтому в Internet Explorer 8 добавлены специальные алгоритмы определения наличия кода в файлах с типом image/*, возможность отключения алгоритма обнаружения и т.п.


Следующая статья данного цикла будет посвящена расширенным сценариям для веб-приложений и, в частности, созданию ускорителей.

javascript — XDomainRequest Vs XMLHttpRequest на IE8 и IE9

Я очень смущен XMLHttpRequest и реинкарнацией XDomainRequest и хотел бы помочь. Итак, вот мои выводы:

  • XDomainRequest в IE8 и IE9 кажется своего рода подкласс класса XMLHttpRequest (?)
  • В XDomainRequest отсутствует «withCredentials»
  • В XDomainRequest отсутствует событие onLoad, заставляющее вас использовать IF состояния и состояния — EDIT: это не совсем так. onLoad доступен, если вы создаете экземпляр XDomainRequest в IE8 и IE9. Если вы создаете XMLHttpRequest в EI8 или IE9, однако, onLoad недоступен. Ниже мы увидим, почему это важно.
  • Кроме того, он представляет данные как простые/текстовые, а не как форму, заставляющую вас анализировать входной поток на задней панели.
  • Даже если директива CORS-сервера «Разрешить заголовки» позволяет считывать Set-Cookie клиентом, XDomainRequest не раскрывает, что делает невозможным использование файлов cookie, хранящихся в cookie, для использования для аутентификации.
  • Наконец, если я не ошибаюсь, он позволяет использовать только методы POST и GET http, которые бесполезны для веб-служб RestFull.

Этот список ни в коем случае не является полным, и, как я сказал, он основан на моих выводах. Однако здесь начинается путаница. У меня есть приложение, где через Ajax я должен:

  • Получить (перекрестный домен) через GET ключ шифрования вместе с идентификатором сеанса, связанным с ним.
  • Зашифруйте мой пароль пользователя с помощью этого ключа (здесь нет проблем)
  • Войдите в кросс-домен (где я получил ключ на шаге 1), используя имя пользователя POST и x-www-form-urlencoded и зашифрованный пароль.

Теперь по всем вышеперечисленным причинам я не могу сделать это с помощью XDomainRequest:

  • Во-первых, поскольку XDomainRequest: open (метод, url) отправляет только обычный текст, и мое стороннее приложение ожидает форму (я могу написать перехватчик фильтра/запроса, но это не так).
  • Поскольку мой идентификатор сеанса, который поступает с ключом шифрования через заголовок Set-Cookie (шаг 1), никогда не отправляется обратно в кросс-домен при входе в систему как заголовок, поскольку XDomainRequest не раскрывает заголовки.

Тем не менее, если в IE8 и IE9 я создаю XMLHttpRequest, игнорируя все эти проверки, описанные здесь, все работает нормально. ОК. Я не получаю событие onload, и я не уверен, что такое история с «withcredentials», но IE8 и IE9, похоже, не имеют проблемы с использованием XMLHttpRequest для кросс-домена. Но почему? Не все ли это противоречиво? Я просто пытаюсь понять это, поскольку я боюсь, что использование XMLHttpRequest в IE8 и IE9 может вернуться и укусить в какой-то момент. Могу ли я попросить ясный пример, когда кто-то может использовать тот, а не другой? Еще лучше, было ли когда-либо обновление IE8 и IE9, которые рассматривали проблему?

Любая помощь будет принята с благодарностью Yiannis

XDomainRequest против XMLHttpRequest на IE8 и IE9

Я очень смущен XMLHttpRequest и реинкарнацией XDomainRequest и хотел бы помочь. Итак, вот мои выводы:


  • XDomainRequest в IE8 и IE9 кажется своего рода подкласс класса XMLHttpRequest (?)
  • В XDomainRequest отсутствует «withCredentials»
  • В XDomainRequest отсутствует событие onLoad, заставляющее вас использовать IF состояния и состояния — EDIT: это не совсем так. onLoad доступен, если вы создаете экземпляр XDomainRequest в IE8 и IE9. Если вы создаете XMLHttpRequest в EI8 или IE9, однако, onLoad недоступен. Ниже мы увидим, почему это важно.
  • Кроме того, он представляет данные как простые/текстовые, а не как форму, заставляющую вас анализировать входной поток на задней панели.
  • Даже если директива CORS-сервера «Разрешить заголовки» позволяет считывать Set-Cookie клиентом, XDomainRequest не раскрывает, что делает невозможным использование файлов cookie, хранящихся в cookie, для использования для аутентификации.
  • Наконец, если я не ошибаюсь, он позволяет использовать только методы POST и GET http, которые бесполезны для веб-служб RestFull.

Этот список ни в коем случае не является полным, и, как я сказал, он основан на моих выводах. Однако здесь начинается путаница. У меня есть приложение, где через Ajax я должен:

  • Получить (перекрестный домен) через GET ключ шифрования вместе с идентификатором сеанса, связанным с ним.
  • Зашифруйте мой пароль пользователя с помощью этого ключа (здесь нет проблем)
  • Войдите в кросс-домен (где я получил ключ на шаге 1), используя имя пользователя POST и x-www-form-urlencoded и зашифрованный пароль.

Теперь по всем вышеперечисленным причинам я не могу сделать это с помощью XDomainRequest:

  • Во-первых, поскольку XDomainRequest: open (метод, url) отправляет только обычный текст, и мое стороннее приложение ожидает форму (я могу написать перехватчик фильтра/запроса, но это не так).
  • Поскольку мой идентификатор сеанса, который поступает с ключом шифрования через заголовок Set-Cookie (шаг 1), никогда не отправляется обратно в кросс-домен при входе в систему как заголовок, поскольку XDomainRequest не раскрывает заголовки.

Тем не менее, если в IE8 и IE9 я создаю XMLHttpRequest, игнорируя все эти проверки, описанные здесь, все работает нормально. ОК. Я не получаю событие onload, и я не уверен, что такое история с «withcredentials», но IE8 и IE9, похоже, не имеют проблемы с использованием XMLHttpRequest для кросс-домена. Но почему? Не все ли это противоречиво? Я просто пытаюсь понять это, поскольку я боюсь, что использование XMLHttpRequest в IE8 и IE9 может вернуться и укусить в какой-то момент. Могу ли я попросить ясный пример, когда кто-то может использовать тот, а не другой? Еще лучше, было ли когда-либо обновление IE8 и IE9, которые рассматривали проблему?

Любая помощь будет принята с благодарностью Yiannis

Internet explorer 8: xdomainrequest

検証したわけではなくググって調べただけですが、以下の記事によると XDomainRequest は IE8 — IE10 で利用できるそうです。

XDomainRequest を含めて IE10 の状態になると思われます。

Windows 10 64-bit の IE11 で試してみましたが、以下のような meta タグを設定するとドキュメントモードが IE10 になって window.XDomainRequest で XDomainRequest オブジェクトは取得できます。

ただし、機能的に IE10 と完全に同じになるかまでは調べてないので分かりませんが。

Илон Маск рекомендует:  Mobile & кпк


上記の記事からリンクが張ってある以下の MSDN ライブラリの「従来の API の追加、変更、および削除」のセクションに «XDomainRequest オブジェクトに代わって XMLHttpRequest の CORS が使われます» と書いてありましたが、完全に削除されたわけではないようです。

なお、meta タグなし(ドキュメントモードは IE11)では window.XDomainRequest は undefined になります。

Cross-Origin Resource Sharing (CORS) を利用したクロスドメインでの ajax 要求・処理を、IE11(またはドキュメントモードが IE10 の IE11)で、XMLHttpRequest を使って可能かということですか?

実際以下の記事の例で試して確認しました。jQuery ajax は XMLHttpRequest を使っています。

Почему XDomainRequest Не Работает В IE8 или IE9

Ниже XDomainRequest, заставляемый от JavaScript до Бэкенда PHP на Nginx на различном субдомене. Результат возвращения всегда выполняет функцию ошибок и , XDomainRequest не предоставляет подробную информацию отладки. Есть ли что-то не так с кодом?

PHP с проверкой вариантов PreFlight

Я получил взаимные требования субдомена работать в любом браузере. Действительно ли там что-то особенное для IE8 и IE9, как специальное предложение Позволять-заголовки или что-то еще, что я пропускаю?

IE, XDomainRequest не всегда работают

Я пытаюсь сделать кросс-домен в IE.

Я использовал XDomainRequest и имплантировал ведение журнала для всех событий (onerror, onload, onprogress и ontimeout) для отслеживания прогресса.

Он работает когда-то, но не всегда (один компьютер, IE9, тот же сайт, тот же запрос, 1 из 3 или 4 работ, другой компьютер, IE8, возможно, 1 из 2 работ). Я не получил никакой полезной информации из журнала, потому что ничего не было вызвано.

Я очень смущен. Любой инструмент отладки для IE? Почему некоторое время XDomainRequest просто не работает?

Большое спасибо коронину

2 Solutions collect form web for “IE, XDomainRequest не всегда работают”


В объекте XDomainRequest имеется по крайней мере две существенные ошибки: одна, которая влияет на IE8, а другая – на IE9.

Выпуск 1 – Сбор мусора

В Internet Explorer 8 объект XDomainRequest некорректно подчиняется сборке мусора после того, как send () был вызван, но еще не завершен. Симптомами этой ошибки являются сетевая трассировка инструментов разработчика, показывающая «Отмена» для запросов и ни один из обработчиков ошибок, тайм-аутов или обработчиков событий.

Типичный код AJAX выглядит примерно так:

В этом примере переменная, содержащая XDomainRequest, выходит за рамки. Если пользователю не повезло, сборщик мусора Javascript IE будет запущен перед отправкой () асинхронно завершен, и запрос будет прерван. Несмотря на то, что объект XDomainRequest может быть захвачен в обработчики событий OnLoad и OnError, IE увидит, что весь граф объекта не имеет ссылок на него и будет собирать мусор. IE должен «привязывать» объект до завершения.

Вы заметите немало других обсуждений в Интернете, в которых упоминается, что размещение setTimeout вокруг xdr.send (); Вызов каким-то образом «решает» загадочные неудачи XDomainRequest. Это куд, и совершенно неверно. Все, что происходит, это то, что объект XDomainRequest «закреплен» в закрытии setTimeout и не подвергается сбору мусора так же быстро. Это не решает проблему.

Чтобы правильно обойти эту проблему, убедитесь, что XDomainRequest хранится в глобальной переменной до тех пор, пока запрос не завершится. Например:

Проблема 2 – Отсутствует OnProgress EventHandler

Эта вторая проблема уже известна. Internet Explorer 9 представил регрессию в объекте XDomainRequest, где отсутствующий (нулевой) обработчик события OnProgress заставит запрос прерывать, когда он пытается сообщить информацию о ходе.

Для быстрых запросов IE9 никогда не пытается вызвать обработчик события OnProgress, и запрос успешно завершен. Некоторые условия, например, когда IE задерживает запрос из-за слишком большого количества открытых подключений, задержки в сети, медленных ответов сервера или больших запросов или полезных данных, заставит IE9 начать сообщать информацию о ходе.

IE9 пытается вызвать обработчик события без предварительной проверки его существования, а объект XDomainRequest вылетает и разрушается внутри.

Чтобы решить эту проблему, всегда убедитесь, что обработчик событий подключен к OnProgress. Учитывая ошибку, неплохо было бы защищать обработчики событий ко всем событиям объекта.

Другие вопросы

Мне кажется, что XDomainRequest может выйти из строя, если обработчики событий зарегистрированы до вызова функции .open (). Опять же, в обороне, неплохо было бы зарегистрировать их между вызовами .open () и .send (). Я лично не проверял, действительно ли это ошибка.

Если вы столкнулись с ошибкой «Отказано в доступе», это связано с тем, что XDomainRequest не разрешает несогласованные схемы URI между целевой и главной страницей. Другими словами, попробуйте не вызывать ресурс HTTP с HTTPS-страницы.


Остерегайтесь большинство библиотек XDomainRequest в Интернете. Я посмотрел на большинство популярных, таких как различные jQuery AJAX транспортные плагины (в том числе те, которые связаны в другом ответе здесь).

И, конечно же, XDomainRequest подчиняется всем нормальным ограничениям и ограничениям . Это не ошибки, а по сравнению с alernatives (iframe kludges, Flash crossdomain.xml transports) они не так уж плохи.

Я разместил новый транспорт jQuery AJAX XDomainRequest под лицензией общественного домена здесь: https://github.com/ebickle/snippets/tree/master/javascript/xdomainrequest

Был тот же самый вопрос. Краткое решение:

  1. Добавить xdr.onprogress = function() <>; В этом файле xdr.js

Подробности можно найти в обсуждении темы jQuery здесь

XDomainRequest против XMLHttpRequest на IE8 и IE9

Я очень смущен XMLHttpRequest и реинкарнацией XDomainRequest и хотел бы помочь. Итак, вот мои выводы:

  • XDomainRequest в IE8 и IE9 кажется своего рода подкласс класса XMLHttpRequest (?)
  • В XDomainRequest отсутствует «withCredentials»
  • В XDomainRequest отсутствует событие onLoad, заставляющее вас использовать IF состояния и состояния — EDIT: это не совсем так. onLoad доступен, если вы создаете экземпляр XDomainRequest в IE8 и IE9. Если вы создаете XMLHttpRequest в EI8 или IE9, однако, onLoad недоступен. Ниже мы увидим, почему это важно.
  • Кроме того, он представляет данные как простые/текстовые, а не как форму, заставляющую вас анализировать входной поток на задней панели.
  • Даже если директива CORS-сервера «Разрешить заголовки» позволяет считывать Set-Cookie клиентом, XDomainRequest не раскрывает, что делает невозможным использование файлов cookie, хранящихся в cookie, для использования для аутентификации.
  • Наконец, если я не ошибаюсь, он позволяет использовать только методы POST и GET http, которые бесполезны для веб-служб RestFull.

Этот список ни в коем случае не является полным, и, как я сказал, он основан на моих выводах. Однако здесь начинается путаница. У меня есть приложение, где через Ajax я должен:

  • Получить (перекрестный домен) через GET ключ шифрования вместе с идентификатором сеанса, связанным с ним.
  • Зашифруйте мой пароль пользователя с помощью этого ключа (здесь нет проблем)
  • Войдите в кросс-домен (где я получил ключ на шаге 1), используя имя пользователя POST и x-www-form-urlencoded и зашифрованный пароль.

Теперь по всем вышеперечисленным причинам я не могу сделать это с помощью XDomainRequest:

  • Во-первых, поскольку XDomainRequest: open (метод, url) отправляет только обычный текст, и мое стороннее приложение ожидает форму (я могу написать перехватчик фильтра/запроса, но это не так).
  • Поскольку мой идентификатор сеанса, который поступает с ключом шифрования через заголовок Set-Cookie (шаг 1), никогда не отправляется обратно в кросс-домен при входе в систему как заголовок, поскольку XDomainRequest не раскрывает заголовки.

Тем не менее, если в IE8 и IE9 я создаю XMLHttpRequest, игнорируя все эти проверки, описанные здесь, все работает нормально. ОК. Я не получаю событие onload, и я не уверен, что такое история с «withcredentials», но IE8 и IE9, похоже, не имеют проблемы с использованием XMLHttpRequest для кросс-домена. Но почему? Не все ли это противоречиво? Я просто пытаюсь понять это, поскольку я боюсь, что использование XMLHttpRequest в IE8 и IE9 может вернуться и укусить в какой-то момент. Могу ли я попросить ясный пример, когда кто-то может использовать тот, а не другой? Еще лучше, было ли когда-либо обновление IE8 и IE9, которые рассматривали проблему?

Любая помощь будет принята с благодарностью Yiannis

Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL