Commit data error xmlhttp undefined что это

XMLHttpRequest помогите

Отправляю вот такой ассинхронный запрос на сервер

var login_vost2 = document.getElementById(‘inp10’).value;
var question_vost2 = document.getElementById(‘select_vost_d’).value;
var reply_vost2 = document.getElementById(‘inp11’).value;

var xmlhttp;
if ( window.XMLHttpRequest ) <
// Для современных браузеров IE7+, Firefox, Chrome, Opera, Safari
xmlhttp = new XMLHttpRequest();
> else <
// Для старых браузеров IE6, IE5
xmlhttp = new ActiveXObject ( «Microsoft.XMLHTTP» );
>

xmlhttp.open ( «POST», «reg_ajax.php», true );
xmlhttp.setRequestHeader(‘Content-Type’, ‘application/x-www-form-urlencoded’);
xmlhttp.setRequestHeader(‘Connection’, ‘close’);
xmlhttp.send («login_vost2=»+login_vost2+»&question_vost2=»+question_vost2+»&reply_vost2=»+reply_vost2);

Если запрос отправляет на сервер цифры или латинские буквы, то сервер видит эти переменные, в вот если русские буквы, то не видит. На сервере я кодировку полученных переменных меняю при помощи фунции iconv(); Это JS код глючит, что не так?

Когд не глючит. Глючит программист. 🙂 Вы посмотрите сами на то, что написали.. .

С одной стороны, Вы пишете:

То есть содержимое запроса якобы идет urlencoded.

С другой стороны, у Вас нигде нет url-кодирования. Данные из формы вставляются в запрос как есть, «сырыми». Для цифр и латинских букв это не имеет значения (символы из первой половины таблицы ASCII при url-кодировании не меняются) , а вот для русских букв это важно.

Читайте документацию по функциям JavaScript escape, encodeURI и encodeURIComponent.

Ну и над кодировками помедитируйте.. . XMLHttpRequest по умолчанию предполагает, что имеет дело с UTF-8. Если у Вас другая кодировка, могут понадобится некоторые действия, чтобы уведомить об этом сервер.. .

Кроме того, в запросе не помешал бы заголовок «Content-Length:».

Источник

XML HTTPRequest: описание, применение, частые проблемы

Здесь Вы найдете полное описание объекта XMLHTTPRequest, способы использования, форматы данных и разбор частых проблем.

Объект XMLHttpRequest

Объект XMLHttpRequest (или, сокращенно, XHR) дает возможность браузеру делать HTTP-запросы к серверу без перезагрузки страницы.

Несмотря на слово XML в названии, XMLHttpRequest может работать с данными в любом текстовом формате, и даже c бинарными данными. Использовать его очень просто.

Кроссбраузерное создание объекта запроса

В зависимости от браузера, код для создания объекта может быть разный.
Кроссбраузерная функция создания XMLHttpRequest:

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

Использование XMLHTTPRequest

Различают два использования XmlHttpRequest. Первое — самое простое, синхронное.

Синхронный XMLHttpRequest

В этом примере через XMLHTTPRequest с сервера запрашивается страница http://example.org/, и текст ответа сервера показывается через alert().

Здесь сначала создается запрос, задается открытие (open) синхронного соединение с адресом /xhr/test.html и запрос отсылается с null,
т.е без данных.

При синхронном запросе браузер «подвисает» и ждет на строчке 3, пока сервер не ответит на запрос. Когда ответ получен — выполняется строка 4, код ответа сравнивается с 200 (ОК), и при помощи alert
печатается текст ответа сервера. Все максимально просто.

Свойство responseText получит такой же текст страницы, как браузер, если бы Вы в перешли на /xhr/test.html. Для сервера
GET-запрос через XmlHttpRequest ничем не отличается от обычного перехода на страницу.

Асинхронный XMLHttpRequest

Этот пример делает то же самое, но асинхронно, т.е браузер не ждет выполнения запроса для продолжения скрипта. Вместо этого к свойству onreadystatechange подвешивается
функция, которую запрос вызовет сам, когда получит ответ с сервера.

Асинхронность включается третьим параметром функции open. В отличие от синхронного запроса, функция send() не останавливает
выполнение скрипта, а просто отправляет запрос.

Запрос xmlhttp регулярно отчитывается о своем состоянии через вызов функции xmlhttp.onreadystatechange. Состояние под номером 4 означает конец выполнения, поэтому функция-обработчик
при каждом вызове проверяет — не настало ли это состояние.

Вообще, список состояний readyState такой:

Состояния 0-2 вообще не используются.

Вызов функции с состоянием Interactive в теории должен происходить каждый раз при получении очередной порции данных от сервера.
Это могло бы быть удобным для обработки ответа по частям, но Internet Explorer не дает доступа к уже полученной части ответа.

Firefox дает такой доступ, но для обработки запроса по частям состояние Interactive все равно неудобно из-за сложностей обнаружения ошибок соединения.
Поэтому Interactive тоже не используется.

На практике используется только последнее, Complete.

Если хотите углубиться в тонкости багов браузеров c readyState, отличными от 4, то многие из них рассмотрены в статье на
Quirksmode (англ.) .

Не используйте синхронные запросы

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

1. Делаем асинхронный запрос
2. Рисуем анимированную картинку или просто запись типа «Loading…»
3. В onreadystatechange при достижении состояния 4 убираем Loading и, в зависимости от status вызываем обработку ответа или ошибки.

Кроме того, иногда полезно ставить ограничение на время запроса. Например, хочется генерировать ошибку, если запрос висит более 10 секунд.

Для этого сразу после send() через setTimeout ставится вызов обработчика ошибки, который очищается при получении ответа и обрывает запрос с генерацией ошибки,
если истекли 10 секунд.

Таймаут на синхронный запрос ставить нельзя, браузер может висеть долго-долго.. А вот на асинхронный — пожалуйста.

Этот пример демонстрирует такой таймаут.

Методы объекта XMLHttpRequest

• open( method, URL )
• open( method, URL, async )
• open( method, URL, async, userName )
• open( method, URL, async, userName, password )

Первый параметр method — HTTP-метод. Как правило, используется GET либо POST, хотя доступны и более экзотические, вроде TRACE/DELETE/PUT и т.п.

URL — адрес запроса. Можно использовать не только HTTP/HTTPS, но и другие протоколы, например FTP и FILE://. При этом есть ограничения безопасности, так называемая
«same origin policy»: запрос со страницы можно отправлять только на тот домен и порт, с которого она пришла.

Ниже это ограничение и способы обхода будут рассмотрены подробнее.

async = true задает асинхронные запросы, эта тема была поднята выше.

userName, password — данные для HTTP-авторизации.

Отсылает запрос. Аргумент — тело запроса. Например, GET-запроса тела нет, поэтому используется send(null) , а для POST-запросов тело содержит параметры запроса.

abort()

Вызов этого метода xmlhttp.abort() обрывает текущий запрос.

Здесь есть одно НО для браузера Internet Explorer. Успешный вызов abort() на самом деле может не обрывать соединение,
а оставлять его в подвешенном состоянии на некоторый таймаут (20-30 секунд). Отловить такие повисшие соединения можно через прокси для отладки, например, Fiddler.

У браузера есть лимит: не более 2 одновременных соединений с одним доменом-портом. Т.е, если два соединения уже висят (и отвиснут по таймауту), то третье открыто не
будет, пока одно из них не умрет. Надеюсь, Вы с такой проблемой не столкнетесь. Ее можно обойти использованием кросс-доменных XmlHttpRequest.

Устанавливает заголовок name запроса со значением value. Если заголовок с таким name уже есть — он заменяется.

Возвращает строку со всеми HTTP-заголовками ответа сервера.

Возвращает значение заголовка ответа сервера с именем headerName.

Свойства объекта XMLHttpRequest

onreadystatechange

Ссылается на функцию-обработчик состояний запроса. В некоторых браузерах функция имеет аргумент — событие. Не используйте его, он совершенно лишний.

readyState

Номер состояния запроса от 0 до 4. Используйте только 4 («completed»).

responseText

Текст ответа сервера. Полный текст есть только при readyState=4, ряд браузеров дают доступ к полученной части ответа сервера при readyState=3.

responseXML

Ответ сервера в виде XML, при readyState=4.

Это свойство хранит объект типа XML document, с которым можно обращаться так же, как с обычным document. Например,

Чтобы браузер распарсил ответ сервера в свойство responseXML, в ответе должен быть заголовок Content-Type: text/xml.

Иначе свойство responseXML будет равно null.

status

Для HTTP-запросов — статусный код ответа сервера: 200 — OK, 404 — Not Found, и т.п. Браузер Internet Explorer может также присвоить status код ошибки WinInet,
например 12029 для ошибки «cannot connect».

Запросы по протоколам FTP, FILE:// не возвращают статуса, поэтому нормальным для них является status=0.

statusText

Текстовая расшифровка status, например «Not Found» или «OK».

GET и POST-запросы. Кодировка.

Во время обычного submit’а формы браузер сам кодирует значения полей и составляет тело GET/POST-запроса для посылки на сервер. При работе через XmlHttpRequest, это нужно делать самим, в javascript-коде. Большинство проблем и вопросов здесь связано с непониманием, где и какое кодирование нужно осуществлять.

Вначале рассмотрим общее кодирование запросов, ниже — правильную работу с русским языком для windows-1251.

Существуют два вида кодирования HTTP-запроса. Основной — urlencoded, он же — стандартное кодирование URL. Пробел представляется как %20, русские буквы и большинство спецсимволов кодируются, английские буквы и дефис оставляются как есть.

Способ, которым следует кодировать данные формы при submit’е, задается в ее HTML-таге:

Источник

Запрос Xmlhttp вызывает ошибку отказа в доступе

Следующий макрос Excel, который отправляет xmlhttp-запрос на эту веб-страницу для получения некоторых значений на втором этапе, некоторое время назад нормально работал в VBA:

Теперь вместо этого при вызове метода:

Объекта msxml2.xmlhttp вызывает следующую ошибку:

Я искал в Интернете, но все подобные темы никогда не отвечали. Может ли кто-нибудь объяснить мне, что означает эта ошибка, и есть ли способ ее исправить или даже просто обойти?

Примечание: случайная строка в конце переменной «Ссылка» была добавлена ​​для принудительной перезагрузки страницы, поскольку скрипт извлекает значения в реальном времени и поэтому должен загружаться каждый раз.

Дополнительная информация: при поиске решения я заметил, что случайная часть ссылки всегда дает одно и то же значение, даже когда я завершаю выполнение и снова перезапускаю:

Почему это происходит? Разве rnd() не должно давать новое случайное значение от 0 до 1 при каждом вызове?

9 ответов

Стандартный запрос, запускаемый с локального компьютера, запрещает доступ к сайтам, которым не доверяет IE. MSXML2.ServerXMLHTTP.6.0 – это серверный объект, который не выполняет эти проверки.

Я обнаружил, что в моем случае изменение http на https устранило проблему отказа в доступе. я могу только предположить, что веб-сайт каким-то образом внес изменения и никому не сказал

Источник

Объект XMLHttpRequest

Объект XMLHttpRequest (или, сокращенно, XHR) дает возможность браузеру делать HTTP-запросы к серверу без перезагрузки страницы.

Несмотря на слово XML в названии, XMLHttpRequest может работать с данными в любом текстовом формате, и даже c бинарными данными. Использовать его очень просто.

Кроссбраузерное создание объекта запроса

В зависимости от браузера, код для создания объекта может быть разный.
Кроссбраузерная функция создания XMLHttpRequest:

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

Использование XMLHTTPRequest

Различают два использования XmlHttpRequest. Первое — самое простое, синхронное.

Синхронный XMLHttpRequest

В этом примере через XMLHTTPRequest с сервера запрашивается страница http://example.org/, и текст ответа сервера показывается через alert().

Здесь сначала создается запрос, задается открытие (open) синхронного соединение с адресом /xhr/test.html и запрос отсылается с null, т.е без данных: send(null).

При синхронном запросе браузер «подвисает» и ждет на строчке 3, пока сервер не ответит на запрос. Когда ответ получен — выполняется строка 4, код ответа сравнивается с 200 (ОК), и при помощи alert печатается текст ответа сервера. Все максимально просто.

Свойство responseText получит такой же текст страницы, как браузер, если бы Вы в перешли на /xhr/test.html. Для сервера GET-запрос через XmlHttpRequest ничем не отличается от обычного перехода на страницу.

Асинхронный XMLHttpRequest

Этот пример делает то же самое, но асинхронно, т.е браузер не ждет выполнения запроса для продолжения скрипта. Вместо этого к свойству onreadystatechange подвешивается функция, которую запрос вызовет сам, когда получит ответ с сервера.

Асинхронность включается третьим параметром функции open. В отличие от синхронного запроса, функция send() не останавливает выполнение скрипта, а просто отправляет запрос.

Запрос xmlhttp регулярно отчитывается о своем состоянии через вызов функции xmlhttp.onreadystatechange. Состояние под номером 4 означает конец выполнения, поэтому функция-обработчик при каждом вызове проверяет — не настало ли это состояние.

Вообще, список состояний readyState такой:

• 0 — Unitialized (Неинициализировано)
• 1 — Loading (Загрузка)
  
• 2 — Loaded (Загружено)
  
• 3 — Interactive (Интерактивное)
  
• 4 — Complete (Выполнено)
  

Состояния 0-2 вообще не используются.

Вызов функции с состоянием Interactive в теории должен происходить каждый раз при получении очередной порции данных от сервера. Это могло бы быть удобным для обработки ответа по частям, но Internet Explorer не дает доступа к уже полученной части ответа.
Firefox дает такой доступ, но для обработки запроса по частям состояние Interactive все равно неудобно из-за сложностей обнаружения ошибок соединения. Поэтому Interactive тоже не используется.

На практике используется только последнее, Complete.

Если хотите углубиться в тонкости багов браузеров c readyState, отличными от 4, то многие из них рассмотрены в статье на Quirksmode (англ.).

Не используйте синхронные запросы

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

1. Делаем асинхронный запрос
2. Рисуем анимированную картинку или просто запись типа «Loading. «
3. В onreadystatechange при достижении состояния 4 убираем Loading и, в зависимости от status вызываем обработку ответа или ошибки.

Кроме того, иногда полезно ставить ограничение на время запроса. Например, хочется генерировать ошибку, если запрос висит более 10 секунд.

Для этого сразу после send() через setTimeout ставится вызов обработчика ошибки, который очищается при получении ответа и обрывает запрос с генерацией ошибки, если истекли 10 секунд.

Таймаут на синхронный запрос ставить нельзя, браузер может висеть долго-долго.. А вот на асинхронный — пожалуйста.

Этот пример демонстрирует такой таймаут.

Методы объекта XMLHttpRequest

• open( method, URL )
• open( method, URL, async )
• open( method, URL, async, userName )
• open( method, URL, async, userName, password )

Первый параметр method — HTTP-метод. Как правило, используется GET либо POST, хотя доступны и более экзотические, вроде TRACE/DELETE/PUT и т.п.

URL — адрес запроса. Можно использовать не только HTTP/HTTPS, но и другие протоколы, например FTP и FILE://. При этом есть ограничения безопасности, так называемая «same origin policy»: запрос со страницы можно отправлять только на тот домен и порт, с которого она пришла.

Ниже это ограничение и способы обхода будут рассмотрены подробнее.

async = true задает асинхронные запросы, эта тема была поднята выше.

userName, password — данные для HTTP-авторизации.

Отсылает запрос. Аргумент — тело запроса. Например, GET-запроса тела нет, поэтому используется send(null) , а для POST-запросов тело содержит параметры запроса.

abort()

Вызов этого метода xmlhttp.abort() обрывает текущий запрос.

Здесь есть одно НО для браузера Internet Explorer. Успешный вызов abort() на самом деле может не обрывать соединение, а оставлять его в подвешенном состоянии на некоторый таймаут (20-30 секунд). Отловить такие повисшие соединения можно через прокси для отладки, например, Fiddler.

У браузера есть лимит: не более 2 одновременных соединений с одним доменом-портом. Т.е, если два соединения уже висят (и отвиснут по таймауту), то третье открыто не будет, пока одно из них не умрет. Надеюсь, Вы с такой проблемой не столкнетесь. Ее можно обойти использованием кросс-доменных XmlHttpRequest.

Устанавливает заголовок name запроса со значением value. Если заголовок с таким name уже есть — он заменяется. Например,

Возвращает строку со всеми HTTP-заголовками ответа сервера.

Возвращает значение заголовка ответа сервера с именем headerName.

Свойства объекта XMLHttpRequest

onreadystatechange

Ссылается на функцию-обработчик состояний запроса. В некоторых браузерах функция имеет аргумент — событие. Не используйте его, он совершенно лишний.

readyState

Номер состояния запроса от 0 до 4. Используйте только 4 («completed»).

responseText

Текст ответа сервера. Полный текст есть только при readyState=4, ряд браузеров дают доступ к полученной части ответа сервера при readyState=3.

responseXML

Ответ сервера в виде XML, при readyState=4.

Это свойство хранит объект типа XML document, с которым можно обращаться так же, как с обычным document. Например,

Чтобы браузер распарсил ответ сервера в свойство responseXML, в ответе должен быть заголовок Content-Type: text/xml.
Иначе свойство responseXML будет равно null.

status

Для HTTP-запросов — статусный код ответа сервера: 200 — OK, 404 — Not Found, и т.п. Браузер Internet Explorer может также присвоить status код ошибки WinInet, например 12029 для ошибки «cannot connect».

Запросы по протоколам FTP, FILE:// не возвращают статуса, поэтому нормальным для них является status=0.

statusText

Текстовая расшифровка status, например «Not Found» или «OK».

GET и POST-запросы. Кодировка.

Во время обычного submit’а формы браузер сам кодирует значения полей и составляет тело GET/POST-запроса для посылки на сервер. При работе через XmlHttpRequest, это нужно делать самим, в javascript-коде. Большинство проблем и вопросов здесь связано с непониманием, где и какое кодирование нужно осуществлять.

Вначале рассмотрим общее кодирование запросов, ниже — правильную работу с русским языком для windows-1251.

Существуют два вида кодирования HTTP-запроса. Основной — urlencoded, он же — стандартное кодирование URL. Пробел представляется как %20, русские буквы и большинство спецсимволов кодируются, английские буквы и дефис оставляются как есть.

Способ, которым следует кодировать данные формы при submit’е, задается в ее HTML-таге:

Если форма submit’ится обычным образом, то браузер сам кодирует (urlencode) название и значение каждого поля данных ( input и т.п.) и отсылает форму на сервер в закодированном виде.

Формируя XmlHttpRequest, мы должны формировать запрос «руками», кодируя поля функцией encodeURIComponent .

Конечно, пропускать через encodeURIComponent стоит только те переменные, в которых могут быть спецсимволы или не английские буквы, т.е которые и будут как раз закодированы.

Например, для посылки GET-запроса с произвольными параметрами name и surname, их необходимо закодировать вот так:

В методе POST параметры передаются не в URL, а в теле, посылаемом через send() . Поэтому params нужно указывать не в адресе, а при вызове send()

Кроме того, при POST обязателен заголовок Content-Type, содержащий кодировку. Это указание для сервера — как обрабатывать (раскодировать) пришедший запрос.

Заголовки Content-Length, Connection в POST-запросах, хотя их и содержат некоторые «руководства», обычно не нужны. Используйте их, только если Вы действительно знаете, что делаете.

Запросы multipart/form-data

Второй способ кодирования — это отсутствие кодирования. Например, кодировать не нужно для пересылки файлов. Он указывается в форме (только для POST) так:

В этом случае при отправке данных на сервер ничего не кодируется. А сервер, со своей стороны, посмотрев на Content-Type(=multipart/form-data), поймет, что пришло.

Возможности XmlHttpRequest позволяют создать запрос с любым телом. Например, можно вручную сделать POST-запрос, загружающий на сервер файл. Функционал создания таких запросов есть, в частности, во фреймворке dojo. Но можно реализовать его и самому, прочитав о нужном формате тела POST и заголовках.

Кодировка (языковая)

Если Вы используете только UTF-8 — пропустите эту секцию.

Все идущие на сервер параметры GET/POST, кроме случая multipart/form-data, кодируются в UTF-8. Не в кодировке страницы, а именно в UTF-8. Поэтому, например, в PHP их нужно при необходимости перекодировать функцией iconv.

С другой стороны, ответ с сервера браузер воспринимает именно в той кодировке, которая указана в заголовке ответа Content-Type. Т.е, опять же, в PHP, чтобы браузер воспринял ответ в windows-1251 и нормально отобразил данные на странице в windows-1251, нужно послать заголовок с кодировкой в php-коде, например так:

Или же, такой заголовок должен добавить сервер. Например, в apache автоматически добавляется кодировка опцией:

Частые проблемы

Кеширование

Многие браузеры поддерживают кеширование ответов на XmlHttpRequest запросы. При этом реализации кеширования немного разные.

Например, при повторном XmlHttpRequest на тот же URL, Firefox посылает запрос с заголовком «If-Modified-Since» со значением, указанным в заголовке «Last-Modified» предыдущего ответа.

А Internet Explorer делает так, только когда кешированный ответ устарел, т.е после времени из заголовка «Expires» предыдущего ответа. Поэтому, кстати, многие думают, что Internet Explorer вообще не очищает кеш ответов.

Самое простое решение проблемы — просто убрать кеширование. Например, при помощи заголовков, или добавлением случайного параметра в URL типа:

Есть, однако, ряд случаев, когда кеширование XMLHttpRequest браузером полезно, улучшает время ответа и экономит трафик, просто нужно уметь его использовать.

Пример демонстрирует универсальный код работы с кешем для Internet Explorer и Firefox. Этот пример обеспечивает посылку «If-Modified-Sinse»-заголовка IE при обращениях к закешированному запросу.

Разбор примера работы с кешем

Внешний тест (1) опирается на то, что в Internet Explorer, если запрос возвращается из кеша без перепроверки, заголовок Date — пустая строка. Поэтому при этом нужно сделать дополнительный запрос, который как раз и будет реальным запросом к серверу.

Когда делаем дополнительный запрос, что ссылку на кешированый запрос сохраняем, т.к если код ответа дополнительного запроса — «304 Not Modified», то его тело будет пустой строкой, и нужно будет вернуться к кешированному объекту.

Для оптимизации, можно не создавать новый объект XmlHttpRequest, а сохранить данные из существующего и использовать заново его же.

Пример выше опирается на то, что сервер всегда выдает заголовок «Date», что верно для большинства конфигураций. В нем делается синхронный запрос. В асинхронном случае, проверку на Date и т.д нужно делать после получения ответа в функции-обработчике onreadystate.

Повторное использование объекта XmlHttpRequest

В Internet Explorer, если open() вызван после установки onreadystatechange, может быть проблема с повторным использованием этого XmlHttpRequest.

Чтобы использовать заново XmlHttpRequest, сначала вызывайте метод open(), а затем — присваивайте onreadystatechange. Это нужно из-за того, что IE самостоятельно очищает объект XmlHttpRequest в методе open(), если его статус «completed».

Вызывать abort() для перенаправления запроса на другой URL не нужно, даже если текущий запрос еще не завершился.

Повторный XmlHttp-запрос после abort() зависает

С этой проблемой я сталкивался только в IE под Windows. Ее причины — в том, что abort() не обрывает TCP-соединение, а оставляет его висеть до наступления таймаута (см. метод abort()). Если же к домену есть два TCP-соединения (даже ждущие таймаута), то третье будет висеть, пока какое-то из них не помрет.

XmlHttpRequest виснет в IE7 (много табов)

Проблема иногда возникает при отладке приложений с длинными XmlHttpRequest, которые висят и ждут события с сервера.

Она связана с ограничением в 2 одновременных соединения к одному домену. Точнее, с тем фактом, что это ограничение в IE7 действует не на один таб, а на все . Так что, если есть два таба с непрерывным соединением, то при открытии третьего таба — XmlHttpRequest с него к тому же домену просто зависнет и будет ждать окончания одного из двух предыдущих запросов.

Утечки памяти

В Internet Explorer объект XmlHttpRequest принадлежит миру DOM/COM, а Javascript-функция — миру Javascript. Присваивание xmlhttp.onreadystatechange = function() < . >задает неявную круговую связь: xmlhttp ссылается на функцию через onreadystatechange, а функция, через свою область видимости — видит (ссылается на) xmlhttp.

Невозможность обнаружить и оборвать такую связь во многих (до IE 6,7 редакции июня 2007?) версиях Internet Explorer приводит к тому, что XmlHttpRequest вместе с ответом сервера, функция-обработчик и всё замыкание прочно оседают в памяти до перезагрузки браузера.

Чтобы этого избежать, ряд фреймворков (YUI, dojo. ) вообще не ставят onreadystatechange, а вместо этого через setTimeout проверяют его readyState каждые 10 миллисекунд. Это разрывает круговую связку xmlhttp onreadystatechange, и утечка памяти не грозит даже в самых глючных браузерах.

Firefox ставит responseXML вида

Да, у браузеров типа Mozilla это такой способ сказать, что документ невалидный.

Ограничения безопасности. Кросс-доменный XMLHttpRequest

Для ограничения XmlHttpRequest используется философия «Same Origin Policy». Она очень проста — каждый сайт в своей песочнице. Запрос можно делать только на адреса с тем же протоколом, доменом, портом, что и текущая страница.

Т.е, со страницы на адресе http://site.com нельзя сделать XmlHttpRequest на адрес https://site.com, http://site.com:81 или http://othersite.com

Это создает проблему, если хочется взять контент с другого сайта. Как правило, в этом случае вместо XmlHttpRequest используются другие средства, например, загрузка через динамически создаваемый тег

Источник

XMLHttpRequest (XMLHTTP, XHR) — API, доступное в скриптовых языках браузеров, таких как JavaScript. Использует запросы HTTP или HTTPS напрямую к веб-серверу и загружает данные ответа сервера напрямую в вызывающий скрипт.^[1] Информация может передаваться в любом текстовом формате, например, в XML, HTML или JSON. Позволяет осуществлять HTTP-запросы к серверу без перезагрузки страницы.

XMLHTTP является важной составляющей технологии AJAX (Asynchronous JavaScript And XML), используется многими сайтами для создания динамичных, быстро реагирующих на запросы пользователя приложений. Например XMLHTTP используется такими сайтами, как Bing Maps, Gmail, Google Maps, Google Suggest, Facebook.

XMLHTTP работает только с файлами, находящимися на том же домене, что и использующая XMLHTTP страница, но существует возможность обойти ограничение. Как и в случае JavaScript, это сделано в целях безопасности (cross-site scripting).

Хотя в названии присутствует аббревиатура XML, технология не накладывает ограничений на формат передаваемых данных. Данные можно пересылать как в виде XML, так и в JSON, HTML или просто неструктурированным текстом. Разработчик может самостоятельно создать формат для передачи данных. Однако нужно учитывать, что при пересылке используется текстовый протокол HTTP и потому при использовании метода GET данные должны передаваться в виде текста (то есть бинарные данные следует кодировать, к примеру в base64). При использовании метода POST в кодировании нет необходимости.

История[]

Впервые был разработан компанией Microsoft, появившись в компоненте Outlook Web Access программного продукта Microsoft Exchange Server 2000. Он был назван IXMLHTTPRequest. Позднее, наработки были включены в состав MSXML 2.0 в виде объекта ActiveX, доступного через JScript, VBScript или другие скриптовые языки, поддерживающиеся браузером. MSXML 2.0 был включён в состав браузера Internet Explorer 5.

Программисты проекта Mozilla затем разработали совместимую версию, называющуюся nsIXMLHttpRequest в Mozilla 0.6. Доступ к компоненту был реализован через JavaScript-объект, названный XMLHttpRequest. Однако, полной функциональности удалось добиться только в Mozilla 1.0. В дальнейшем поддержка XMLHttpRequest появилась в браузерах Safari 1.2, Opera 8.01 и в других.

Последняя официальная спецификация — версия 1.0 (XMLHttpRequest от 19 декабря 2012 года), которая имеет статус текущего стандарта (Living Standard) и версия 2.0 (XMLHttpRequest Level 2 от 17 января 2012 года), имеющая статус рабочего варианта. Во второй версии вводятся обработчики событий прогресса, поддержка кросс-доменных запросов и работа с бинарными данными.^[2]

Свойства класса XMLHttpRequest[]

Ошибки, вызываемые классом XMLHttpRequest[]

Пример использования[]

План работы с объектом XMLHttpRequest можно представить следующим образом:

1. Создание экземпляра объекта XMLHttpRequest
2. Открытие соединения
3. Установка обработчика события (нужно делать после открытия и до отправки в IE)
4. Отправка запроса.

Создание экземпляра объекта XMLHttpRequest.
На этой стадии необходима отдельная реализация для разных браузеров. Конструкция создания объекта отличается: в IE 5 — IE 6 она реализована через ActiveXObject, а в остальных браузерах (IE 7 и выше, Mozilla, Opera, Chrome, Netscape и Safari) — как встроенный объект типа XMLHttpRequest.

Вызов для ранних версий Internet Explorer выглядит так^[3]:

var req = new ActiveXObject("Microsoft.XMLHTTP");

В остальных браузерах:

var req = new XMLHttpRequest();

То есть, для обеспечения кросс-браузерности кода, нужно лишь проверять наличие объектов window.XMLHttpRequest и window.ActiveXObject, и, в зависимости от того, какой есть, тот и применять.

В качестве универсального решения предлагается использование такой функции:

function createRequestObject() {
  if (typeof XMLHttpRequest === 'undefined') {
    XMLHttpRequest = function() {
      try { return new ActiveXObject("Msxml2.XMLHTTP.6.0"); }
        catch(e) {}
      try { return new ActiveXObject("Msxml2.XMLHTTP.3.0"); }
        catch(e) {}
      try { return new ActiveXObject("Msxml2.XMLHTTP"); }
        catch(e) {}
      try { return new ActiveXObject("Microsoft.XMLHTTP"); }
        catch(e) {}
      throw new Error("This browser does not support XMLHttpRequest.");
    };
  }
  return new XMLHttpRequest();
}

Установка обработчика событий, открытие соединения и отправка запросов

Эти вызовы выглядят так:

req.open(<"GET"|"POST"|...>, <url>[, <asyncFlag>[, <user>, <password>]]);
req.onreadystatechange = processReqChange;

Где:

• <«GET»|«POST»|…> — метод запроса. Допускаются: DELETE, GET, HEAD, OPTIONS, POST, PUT.
• <url> — адрес запроса.
• <asyncFlag> — флаг, определяющий, использовать ли асинхронный запрос. По умолчанию, установлен в true.
• <user>, <password> — логин и пароль, соответственно. Указываются при необходимости.

После определения всех параметров запроса его остается только отправить. Делается это методом send(). При отправке GET-запроса для версии без ActiveX необходимо указать параметр null, в остальных случаях можно не указывать никаких параметров. Не будет ошибкой, если для GET всегда будет указан параметр null:

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

var req;

function loadXMLDoc(url)
{
    req = null;
    if (window.XMLHttpRequest) {
        try {
            req = new XMLHttpRequest();
        } catch (e){}
    } else if (window.ActiveXObject) {
        try {
            req = new ActiveXObject('Msxml2.XMLHTTP');
        } catch (e){
            try {
                req = new ActiveXObject('Microsoft.XMLHTTP');
            } catch (e){}
        }
    }

    if (req) {       
        req.open("GET", url, true);
        req.onreadystatechange = processReqChange;
        req.send(null);
    }
}

function processReqChange()
{
  try { // Важно!
    // только при состоянии "complete"
    if (req.readyState == 4) {
        // для статуса "OK"
        if (req.status == 200) {
            // обработка ответа
        } else {
            alert("Не удалось получить данные:n" +
                req.statusText);
        }
    }
  }
  catch( e ) {
      // alert('Ошибка: ' + e.description);
      // В связи с багом XMLHttpRequest в Firefox приходится отлавливать ошибку
      // Bugzilla Bug 238559 XMLHttpRequest needs a way to report networking errors
      // https://bugzilla.mozilla.org/show_bug.cgi?id=238559
  }
}

Известные проблемы[]

Шаблон:В планах

См. также[]

• AJAX
• HTTP
• REST

Ссылки[]

История[]

• История XMLHTTP глазами одного из разработчиков Шаблон:Ref-en

Реализация в браузерах[]

• Apple Safari и KDE Konqueror
• Microsoft IXMLHTTPRequest
• Mozilla nsIXMLHttpRequest
• Mozilla XMLHttpRequest object HowTo
• Mozilla XML Extras
• Opera для компьютеров и для мобильных телефонов

Учебные руководства[]

• XMLHTTPRequest: описание, применение, частые проблемы
• Сверхдинамичные веб-интерфейсы

Стандарты[]

• Создана рабочая группа по стандартизации XMLHTTPRequest во всех браузерах

Литература[]

• Шаблон:±. AJAX в действии: технология — Asynchronous JavaScript and XML = Ajax in Action. — Шаблон:Указание места в библиоссылке: «Вильямс», 2006. — С. 640. — ISBN 1-932394-61-3.
• Шаблон:±. AJAX и PHP: разработка динамических веб-приложений. — Шаблон:Указание места в библиоссылке: Символ Плюс, 2006. — С. 336. — ISBN 5-93286-077-4.

Шаблон:Microsoft APIs
Шаблон:Стандарты W3C
Шаблон:Windows API