Для многих веб-разработчиков достаточно создания простых запросов и получения простых ответов, но для разработчиков, которые хотят освоить Ajax, необходимо полное понимание кодов состояния HTTP, состояний готовности и объекта XMLHttpRequest; В этой статье Бретт Маклафлин знакомит вас с различными кодами состояния и показывает, как браузеры их обрабатывают. Он также рассматривает некоторые менее распространенные HTTP-запросы, используемые в Ajax.
В предыдущей статье этой серии мы подробно рассмотрели объект XMLHttpRequest, который является центральным элементом приложения Ajax и отвечает за обработку запросов от серверных приложений и сценариев, а также обработку данных, возвращаемых серверными компонентами. Поскольку все приложения Ajax используют объект XMLHttpRequest, вам может потребоваться ознакомиться с этим объектом, чтобы Ajax мог работать лучше.
В этой статье я сосредоточусь на трех ключевых частях этого объекта запроса на основе предыдущей статьи:
· Статус готовности HTTP · Код состояния HTTP · Типы запросов, которые могут быть сгенерированы.
Все эти три части относятся к построению факторов, которые следует учитывать. однако при запросе на эти темы написано слишком мало; Однако, если вы хотите узнать больше, чем просто основы Ajax-программирования, вам необходимо ознакомиться с содержимым состояний готовности, кодами состояний и самими запросами. Когда с вашим приложением что-то идет не так (а так всегда бывает), если вы правильно понимаете состояние готовности, как сгенерировать запрос HEAD или что именно означает код состояния 400, вы можете отладить проблему за 5 минут вместо потраченных 5 часов. в различных разочарованиях и смятениях.
Давайте сначала посмотрим на состояние готовности HTTP.
Более пристальный взгляд на состояние готовности HTTP.
Из предыдущей статьи вы помните, что объект XMLHttpRequest имеет свойство ReadyState. Этот атрибут гарантирует, что сервер выполнил запрос, обычно используя функцию обратного вызова для чтения данных с сервера для обновления содержимого веб-формы или страницы. В листинге 1 показан простой пример (это также пример из предыдущей статьи этой серии — см. Ресурсы).
XMLHttpRequest или XMLHttp: изменение имени
Microsoft™ и Internet Explorer используют объект XMLHttp вместо объекта XMLHttpRequest, который используется Mozilla, Opera, Safari и большинством браузеров сторонних производителей. Для простоты я буду называть оба объекта просто XMLHttpRequest. Это согласуется как с тем, что мы видим в Интернете, так и с намерением Microsoft использовать XMLHttpRequest в качестве объекта запроса в Internet Explorer 7.0. (Подробнее об этом вопросе см. в части 2.)
Листинг 1. Обработка ответа сервера в
функции обратного вызова updatePage() {
если (request.readyState == 4) {
если (запрос.статус == 200) {
вар ответ = request.responseText.split("|");
document.getElementById("order").value = ответ[0];
document.getElementById("адрес").innerHTML =
ответ[1].replace(/n/g, "<br />");
} еще
alert("статус " + request.status);
}
}
Очевидно, это наиболее распространенное (и простое) использование состояния готовности. Как видно по цифре «4», есть еще несколько готовых состояний (вы также видели этот список в предыдущей статье — см. Ресурсы):
· 0: запрос не инициализирован (open() еще не вызывался) .
·1: Запрос установлен, но не отправлен (send() еще не был вызван).
·2: Запрос отправлен и обрабатывается (обычно заголовки содержимого теперь можно получить из ответа).
·3: запрос обрабатывается; обычно в ответе имеются некоторые данные, но сервер еще не завершил генерацию ответа.
·4: ответ завершен; вы можете получить и использовать ответ сервера.
Если вы хотите понять больше, чем просто основы Ajax-программирования, вам необходимо знать не только эти состояния, но и то, когда они возникают и как их использовать. Во-первых, вам необходимо узнать, с какими состояниями запроса вы можете столкнуться в каждом состоянии готовности. К сожалению, это не интуитивно понятно и включает несколько особых случаев.
Скрытое состояние готовности.
Первое состояние готовности характеризуется тем, что атрибут ReadyState равен 0 (readyState == 0), что указывает на неинициализированное состояние. Это свойство устанавливается в 1, как только open() вызывается для объекта запроса. Поскольку вы обычно вызываете open() сразу после инициализации пары запросов, вы редко увидите состояние ReadyState == 0. Кроме того, неинициализированное состояние готовности не имеет реального применения в реальных приложениях.
Но для нашего интереса см. листинг 2, в котором показано, как получить состояние готовности, когда для параметра ReadyState установлено значение 0.
Листинг 2. Получение статуса готовности 0
функция getSalesData() {
//Создаем объект запроса
создатьЗапрос();
alert("Состояние готовности: " + request.readyState
// Настройка (инициализация) запроса;
var url = "/boards/servlet/UpdateBoardSales";
request.open("GET", URL, правда);
request.onreadystatechange = updatePage;
запрос.отправить (ноль);
}
В этом простом примере getSalesData() — это функция, которую веб-страница вызывает для инициирования запроса (например, при нажатии кнопки). Обратите внимание, что вы должны проверить статус готовности перед вызовом open(). На рис. 1 показаны результаты запуска этого приложения.
Рисунок 1. Состояние готовности 0
Очевидно, что это не принесет вам много пользы; существует очень мало ситуаций, когда вам нужно убедиться, что функция open() еще не была вызвана. В реальном мире большинства программ Ajax единственным способом использования этого состояния готовности является использование одного и того же объекта XMLHttpRequest для генерации нескольких запросов к нескольким функциям. В этом (редком) случае вам может потребоваться убедиться, что объект запроса находится в неинициализированном состоянии (readyState == 0) перед генерацией нового запроса. По сути, это гарантирует, что другая функция не будет использовать объект одновременно.
Просмотр состояния готовности обрабатываемого запроса
. Помимо состояния готовности 0, объект запроса также должен пройти несколько других состояний готовности типичных запросов и ответов и, наконец, заканчивается в виде состояния готовности 4. Вот почему вы видите строку if (request.readyState == 4) в большинстве функций обратного вызова; она гарантирует, что сервер завершил обработку запроса и теперь можно безопасно обновлять веб-страницу или обновлять страницу на основе возвращенного запроса. данные с сервера для выполнения операций.
Очень просто увидеть, как возникает это состояние. Если статус готовности равен 4, нам нужно не только запускать код в функции обратного вызова, но мы также печатаем статус готовности каждый раз, когда вызывается функция обратного вызова. В листинге 3 приведен пример реализации этой функциональности.
Если 0 равно 4
, вам необходимо проверить статус готовности 0, чтобы убедиться, что объект запроса не используется, когда несколько функций JavaScript используют один и тот же объект запроса. Этот механизм может вызвать проблемы. Поскольку ReadyState == 4 представляет собой завершенный запрос, вы часто обнаружите, что объекты запроса в состоянии готовности, которые в данный момент не используются, по-прежнему имеют значение 4 — это потому, что данные, возвращенные с сервера, уже были использованы, но нет. изменения были внесены с момента их перевода в состояние готовности. Существует функция abort(), которая сбрасывает объект запроса, но на самом деле эта функция для этой цели не используется. Если вам необходимо использовать несколько функций, лучше создать и использовать одну функцию для каждой функции, а не использовать один и тот же объект для нескольких функций.
Листинг 3. Просмотр
функции готовности updatePage() {
// Выводим текущее состояние готовности
alert("updatePage() вызывается с состоянием готовности " + request.readyState);
}
Если вы не уверены, как запустить эту функцию, вам нужно создать функцию, затем вызвать эту функцию на веб-странице и отправить ей запрос серверному компоненту (например, функция, показанная в листинге 2, или функция в этой серии статей) Примеры приведены в части 1 и части 2). При выполнении запроса обязательно установите функцию обратного вызова на updatePage(), установите для свойства onreadystatechange объекта запроса значение updatePage();
Этот код является точной демонстрацией значения onreadystatechange — каждый раз, когда состояние готовности запроса меняется, вызывается updatePage(), и тогда мы видим предупреждение. На рисунке 2 показан пример вызова этой функции, где статус готовности равен 1.
Рисунок 2. Состояние готовности 1
Вы можете попробовать запустить этот код самостоятельно. Поместите его на веб-страницу и активируйте обработчик событий (нажмите кнопку, перейдите на вкладку между полями или используйте любой установленный вами метод для запуска запроса). Эта функция обратного вызова будет выполняться несколько раз — каждый раз при изменении состояния готовности — и вы можете увидеть предупреждение для каждого состояния готовности. Это лучший способ отслеживать различные этапы, которые проходит запрос.
Несоответствия браузера
После того, как вы получите общее представление о процессе, попробуйте получить доступ к своей странице из нескольких разных браузеров. Вы должны заметить, что браузеры по-разному обрабатывают эти состояния готовности. Например, в Firefox 1.5 вы увидите следующие состояния готовности:
·1
·2
·3
·4
Это неудивительно, поскольку здесь представлен каждый статус запроса. Однако если вы используете Safari для доступа к тому же приложению, вы должны увидеть (или нет) что-то интересное. Вот как это выглядит в Safari 2.0.1:
·2
·3
·4
Safari на самом деле отбрасывает первое состояние готовности, и нет очевидной причины, почему, но Safari работает именно так; Это также иллюстрирует важный момент: хотя перед использованием данных на сервере рекомендуется убедиться, что статус запроса равен 4, код, написанный с учетом каждого переходного состояния готовности, действительно будет выглядеть по-разному в результатах разных браузеров.
Например, при использовании Opera 8.5 отображаемый статус готовности еще хуже:
·3
·
4Наконец, Internet Explorer отобразит следующий статус:
·1
·2
·3
·4Если
у вас возникли проблемы с вашими запросами, это первое место, куда можно обратиться, чтобы выявить проблему. Лучший способ — протестировать это как в Internet Explorer, так и в Firefox — вы увидите все 4 состояния и сможете проверить, в каком состоянии находится каждое состояние запроса.
Далее давайте посмотрим на ситуацию со стороны ответа.
Данные ответа под микроскопом
Как только мы поймем различные состояния готовности, возникающие в процессе запроса, пришло время взглянуть на другой аспект объекта XMLHttpRequest — атрибут responseText. Напомним, что мы представили в предыдущей статье: вы можете знать, что этот атрибут используется для получения данных с сервера. Как только сервер завершит обработку запроса, он может поместить любые данные, необходимые для ответа на данные запроса, в текст ответа запроса. Затем функция обратного вызова может использовать эти данные, как показано в листинге 1 и листинге 4.
Листинг 4. Использование ответа, возвращенного сервером
функция обновления страницы() {
если (request.readyState == 4) {
вар newTotal = request.responseText;
var totalSoldEl = document.getElementById("всего-продано");
var netProfitEl = document.getElementById("чистая прибыль");
replaceText(totalSoldEl, newTotal)
/* Представьте новую чистую прибыль */;
var boardCostEl = document.getElementById("стоимость доски");
вар boardCost = getText(boardCostEl);
var manCostEl = document.getElementById("man-cost");
вар manCost = getText(manCostEl);
варprofitPerBoard = boardCost - manCost;
var netProfit =profitPerBoard * newTotal;
/* Обновление чистой прибыли в форме продаж */
чистая прибыль = Math.round(чистая прибыль * 100) / 100;
replaceText(netProfitEl, netProfit);
Листинг
1 довольно прост; Листинг 4 немного сложнее, но они оба вначале проверяют состояние готовности и получают значение свойства responseText.
Просмотр текста ответа на запрос
Как и в состоянии готовности, значение свойства responseText также меняется на протяжении всего срока действия запроса. Чтобы увидеть это изменение, используйте код, показанный в листинге 5, для проверки текста ответа на запрос, а также его состояния готовности.
Листинг 5. Тестирование свойства responseText
function updatePage() {
// Выводим текущее состояние готовности
alert("updatePage() вызывается с состоянием готовности " + request.readyState +
" и текст ответа '" + request.responseText + "'");
}
Теперь откройте веб-приложение в браузере и активируйте свой запрос. Чтобы лучше увидеть эффект этого кода, используйте Firefox или Internet Explorer, поскольку оба браузера могут сообщать обо всех возможных состояниях готовности во время запроса. Например, в состоянии готовности 2 ответный текст не определен (см. рис. 3), если консоль JavaScript также открыта, вы увидите ошибку;
Рисунок 3. Текст ответа для статуса готовности 2
Однако в состоянии готовности 3 сервер поместил значение в свойство responseText, по крайней мере, в этом примере (см. рис. 4).
Рисунок 4. Текст ответа для статуса готовности 3
Вы увидите, что ответ со статусом готовности 3 различен для каждого скрипта, каждого сервера и даже каждого браузера. Однако это по-прежнему очень полезно при отладке приложений.
Получение защищенных данных
Во всех документах и спецификациях подчеркивается, что данные можно безопасно использовать только при статусе готовности 4. Поверьте, когда состояние готовности равно 3, вы редко встретите ситуацию, когда вы не сможете получить данные из свойства responseText. Однако не стоит делать собственную логику приложения зависимой от состояния готовности 3 — как только вы пишете код, опирающийся на полные данные в состоянии готовности 3, вы практически несете ответственность за неполные данные в этот момент.
Лучший подход — предоставить пользователю некоторую информацию о том, что, когда он находится в состоянии готовности 3, ответ будет скоро. Хотя использование таких функций, как alert(), очевидно, является плохой идеей — использовать Ajax, а затем блокировать пользователя с помощью диалогового окна предупреждения, очевидно, неправильно — вы можете обновлять поля в форме или на странице при изменении состояния готовности. Например, для состояния готовности 1 установите ширину индикатора выполнения на 25 %, для состояния готовности 2 установите ширину индикатора выполнения на 50 %, а для состояния готовности 3 установите ширину индикатора выполнения на 25. %. Ширина устанавливается на 75 %, а когда состояние готовности равно 4, ширина индикатора выполнения устанавливается на 100 % (завершено).
Конечно, как вы уже видели, этот метод очень умный, но он зависит от браузера. В Opera вы никогда не увидите первые два состояния готовности, а в Safari нет первого (1). По этой причине я оставил этот код в качестве упражнения и не включил его в эту статью.
Теперь пришло время взглянуть на коды состояния.
Более глубокий взгляд на коды состояния HTTP
Имея состояние готовности и ответ сервера, которые вы изучили в разделе «Техники программирования Ajax», вы можете добавить еще один уровень сложности к своим приложениям Ajax — используя коды состояния HTTP. В этом коде нет ничего нового об Ajax. Они существуют с момента зарождения Интернета. Возможно, вы видели несколько кодов состояния в веб-браузерах:
· 401: Несанкционировано · 403: Запрещено · 404: Не найдено.
Дополнительные коды состояния можно найти (полный список см. в разделе «Ресурсы»). Чтобы добавить дополнительный уровень механизмов управления и реагирования (и более надежную обработку ошибок) в ваши приложения Ajax, вам необходимо правильно просматривать коды состояния в запросах и ответах.
200: Все в порядке.
Во многих Ajax-приложениях вы увидите функцию обратного вызова, которая отвечает за проверку состояния готовности, а затем продолжает использовать данные, возвращенные из ответа сервера, как показано в листинге 6.
Листинг 6. Функция обратного вызова, игнорирующая код состояния
function updatePage() {
если (request.readyState == 4) {
вар ответ = request.responseText.split("|");
document.getElementById("order").value = ответ[0];
document.getElementById("адрес").innerHTML =
ответ[1].replace(/n/g, "<br />");
}
}
Это оказывается недальновидным и неправильным подходом к Ajax-программированию. Если сценарий требует аутентификации и запрос не предоставляет действительный сертификат, сервер возвращает код ошибки, например 403 или 401. Однако, поскольку сервер ответил на запрос, статус готовности устанавливается на 4 (даже если ответ не соответствует ожиданиям запроса). В конечном итоге пользователь не получает действительных данных, и могут возникнуть серьезные ошибки, когда JavaScript пытается использовать несуществующие данные сервера.
Требуется минимум усилий, чтобы сервер не только выполнил запрос, но и вернул код состояния «все хорошо». Этот код — «200», о чем сообщается через атрибут состояния объекта XMLHttpRequest. Чтобы гарантировать, что сервер не только выполнил запрос, но и сообщил о состоянии «ОК», добавьте еще одну проверку в функцию обратного вызова, как показано в листинге 7.
Листинг 7. Проверка допустимых кодов состояния
function updatePage() {
если (request.readyState == 4) {
если (запрос.статус == 200) {
вар ответ = request.responseText.split("|");
document.getElementById("order").value = ответ[0];
document.getElementById("адрес").innerHTML =
ответ[1].replace(/n/g, "<br />");
} еще
alert("статус " + request.status);
}
}
Добавив эти несколько строк кода, вы сможете подтвердить наличие проблемы, и пользователь увидит полезное сообщение об ошибке, а не просто увидит страницу, состоящую из данных, вырванных из контекста без объяснения причин.
Перенаправления и перенаправления
Прежде чем мы углубимся в подробности ошибок, стоит обсудить проблему, о которой не нужно беспокоиться при использовании Ajax — перенаправления. Среди кодов состояния HTTP это серия кодов состояния 300, в том числе:
301: перемещено навсегда; 302: найдено (запрос перенаправлен на другой URL/URI).
·305: Использование прокси (запрос должен использовать прокси для доступа к запрошенному ресурсу).
Программисты Ajax могут не слишком беспокоиться о проблемах перенаправления по двум причинам:
·Во-первых, приложения Ajax обычно разрабатываются для написания для конкретной серверной стороны. сценарий, сервлет или приложение. Программисты Ajax менее четко понимают компоненты, которые исчезают, даже если вы их не видите. Поэтому иногда вы знаете, что ресурс был перемещен (потому что вы его переместили или переместили каким-то образом), а затем вы изменяете URL-адрес в запросе и никогда больше не сталкиваетесь с этим результатом.
Более важная причина заключается в том, что приложения и запросы Ajax инкапсулируются в «песочнице». Это означает, что домен, который обслуживает веб-страницы, генерирующие запросы Ajax, должен быть доменом, отвечающим на эти запросы. Таким образом, веб-страница, предоставленная ebay.com, не может отправить запрос в стиле Ajax к сценарию, работающему на amazon.com; приложение Ajax на ibm.com не может отправить запрос к сервлетам, работающим на netbeans.org.
·В результате ваш запрос не может быть перенаправлен на другой сервер без возникновения ошибки безопасности. В этих случаях вы вообще не получите код состояния. Обычно в консоли отладки генерируется ошибка JavaScript. Таким образом, после достаточного размышления о кодах состояния, вы можете вообще игнорировать проблему кодов перенаправления.
В результате ваш запрос не может быть перенаправлен на другой сервер без возникновения ошибки безопасности. В этих случаях вы вообще не получите код состояния. Обычно в консоли отладки генерируется ошибка JavaScript. Таким образом, после достаточного размышления о кодах состояния, вы можете вообще игнорировать проблему кодов перенаправления.
Ошибки
Как только вы получите код состояния 200 и поймете, что можете игнорировать коды состояния серии 300, единственный набор кодов, о которых вам нужно беспокоиться, — это коды серии 400, которые иллюстрируют различные типы ошибок. Вернитесь к листингу 7 и обратите внимание, что при обработке ошибок пользователю выводятся лишь несколько распространенных сообщений об ошибках. Хотя это шаг в правильном направлении, эти сообщения по-прежнему не очень полезны для информирования пользователей и программистов, работающих над приложением, что именно происходит не так.
Во-первых, мы добавим поддержку не найденных страниц. На самом деле этого не должно происходить в большинстве производственных систем, но нередко случается, что местоположение тестового сценария меняется или программист вводит неверный URL-адрес. Если вы можете сообщать об ошибках 404 естественным образом, вы можете оказать больше помощи разочарованным пользователям и программистам. Например, если сценарий на сервере удален, мы можем использовать код из листинга 7, чтобы пользователь видел неописательную ошибку, подобную той, что показана на рисунке 5.
Крайние случаи и сложные ситуации
На этом этапе некоторые начинающие программисты могут задаться вопросом, о чем идет речь. Вот факт, который вам нужно знать: менее 5% запросов Ajax используют состояния готовности, такие как 2 и 3, и коды состояния, такие как 403 (на самом деле этот показатель, вероятно, ближе к 1% или даже меньше). Эти ситуации очень важны и называются крайними случаями — они возникают только в очень специфических ситуациях, когда возникают самые экзотические проблемы. Хотя такие ситуации не являются распространенными, на эти крайние случаи приходится 80% проблем, с которыми сталкивается большинство пользователей!
Для обычного пользователя тот факт, что приложение работает правильно 100 раз, обычно забывается, однако одну ошибку в приложении он четко запомнит! их. Если вы умеете хорошо справляться с крайними случаями (или трудными ситуациями), вы можете обеспечить удовлетворительное вознаграждение для пользователей, которые возвращаются на ваш сайт.
Рисунок 5. Обработка типичных ошибок
Пользователь не может определить, является ли проблема проблемой аутентификации, не найденным сценарием (как в данном случае), ошибкой пользователя или чем-то еще в коде. Добавление простого кода может сделать эту ошибку более конкретной. Пожалуйста, обратитесь к листингу 8, который отвечает за обработку ситуации, когда сценарий не найден или возникает ошибка аутентификации, и при возникновении этих ошибок будут выдаваться специальные сообщения.
Листинг 8. Проверка допустимых кодов состояния
function updatePage() {
если (request.readyState == 4) {
если (запрос.статус == 200) {
вар ответ = request.responseText.split("|");
document.getElementById("order").value = ответ[0];
document.getElementById("адрес").innerHTML =
ответ[1].replace(/n/g, "<br />");
} еще если (request.status == 404) {
предупреждение («Запрошенный URL-адрес не найден.»);
} еще если (request.status == 403) {
alert("Доступ запрещен.");
} еще
alert("статус " + request.status);
}
}
Хотя это все еще довольно просто, но дает немного больше полезной информации. На рис. 6 показана та же ошибка, что и на рис. 5, но на этот раз код обработки ошибок лучше объясняет пользователю или программисту, что именно произошло.
Рисунок 6. Специальная обработка ошибок
В нашем собственном приложении мы могли бы рассмотреть возможность очистки имени пользователя и пароля и добавления сообщения об ошибке на экран в случае сбоя аутентификации. Мы можем использовать аналогичный подход для лучшей обработки сценария, который не найден, или других ошибок типа 400 (например, 405 означает, что неприемлемый метод запроса, такой как отправка запроса HEAD, не разрешен, а 407 означает, что требуется аутентификация прокси). Однако независимо от того, какой вариант вы выберете, вам необходимо начать обработку кода состояния, возвращаемого с сервера.
Другие типы запросов
Если вы действительно хотите иметь контроль над объектом XMLHttpRequest, рассмотрите возможность реализации этой последней функции, добавив запрос HEAD в директиву. В двух предыдущих статьях мы рассказали, как генерировать запросы GET; в следующей статье вы узнаете об использовании запросов POST для отправки данных на сервер. Однако в духе расширенной обработки ошибок и сбора информации вам следует научиться генерировать запросы HEAD.
Выполнение запроса
Выполнение запроса HEAD на самом деле очень просто: вы вызываете метод open() с «HEAD» (вместо «GET» или «POST») в качестве первого параметра, как показано в листинге 9.
Листинг 9. Использование Ajax для генерации запроса HEAD
function getSalesData() {
создатьЗапрос();
var url = "/boards/servlet/UpdateBoardSales";
request.open("HEAD", URL, true);
request.onreadystatechange = updatePage;
запрос.отправить (ноль);
}
Когда вы генерируете такой запрос HEAD, сервер не возвращает реальный ответ, как это было бы для запроса GET или POST. Вместо этого сервер возвращает только заголовок ресурса, который включает дату последнего изменения содержимого ответа, существование запрошенного ресурса и множество другой полезной информации. Вы можете использовать эту информацию, чтобы узнать о ресурсе до его обработки и возврата сервером.
Самое простое, что вы можете сделать для такого типа запроса, — это просто вывести содержимое всех заголовков ответа. Это дает вам представление о том, что доступно по запросу HEAD. В листинге 10 представлена простая функция обратного вызова, которая печатает содержимое заголовка ответа, полученного по запросу HEAD.
Листинг 10. Вывод содержимого заголовка ответа, полученного в результате запроса HEAD
function updatePage() {
если (request.readyState == 4) {
оповещение(request.getAllResponseHeaders());
}
}
См. рисунок 7, на котором показаны заголовки ответов, возвращаемые простым Ajax-приложением, которое отправляет запрос HEAD серверу.
Вы можете использовать эти заголовки индивидуально (от типа сервера до типа контента) для предоставления дополнительной информации или функций в вашем приложении Ajax.
Проверка URL-адреса
Вы видели, как проверить наличие ошибок 404, если URL-адрес не существует. Если это обычная проблема (возможно, отсутствует конкретный сценарий или сервлет), возможно, вам захочется проверить URL-адрес перед выполнением полного запроса GET или POST. Чтобы реализовать эту функцию, сгенерируйте запрос HEAD, а затем проверьте наличие ошибок 404 в функции обратного вызова. В листинге 11 показана простая функция обратного вызова.
Листинг 11. Проверка существования URL-адреса
function updatePage() {
если (request.readyState == 4) {
если (запрос.статус == 200) {
alert("URL существует");
} еще если (request.status == 404) {
alert("URL-адрес не существует.");
} еще {
alert("Статус: " + request.status);
}
}
}
Честно говоря, ценность этого кода не так уж и велика. Сервер должен ответить на запрос и создать ответ, дополняющий заголовок ответа Content-Length, чтобы не экономить время обработки. Кроме того, это занимает столько же времени, сколько генерация запроса и использование запроса HEAD для проверки существования URL-адреса, поскольку запрос генерируется с использованием GET или POST, а не просто обрабатывается код ошибки, как показано в листинге 7. Однако иногда полезно точно знать, что доступно в данный момент; никогда не знаешь, когда проявится ваша креативность или когда вам понадобится запрос HEAD!
Полезные запросы HEAD
Одна из областей, где запрос HEAD может оказаться очень полезным, — это просмотр длины или типа контента. Это может определить, нужно ли отправить обратно большой объем данных для обработки запроса и пытается ли сервер вернуть двоичные данные вместо HTML, текста или XML (все три типа данных легче обрабатывать в JavaScript, чем в JavaScript). двоичные данные).
В этих случаях вы просто используете подходящее имя заголовка и передаете его методу getResponseHeader() объекта XMLHttpRequest. Итак, чтобы получить длину ответа, просто вызовите request.getResponseHeader("Content-Length");. Чтобы получить тип контента, используйте request.getResponseHeader("Content-Type");.
Во многих приложениях создание запроса HEAD не добавляет никакой функциональности и может даже привести к замедлению запроса (заставляя запрос HEAD получать данные об ответе, а затем используя запрос GET или POST для фактического получения ответа). Однако в ситуациях, когда вы не уверены в сценарии или серверном компоненте, использование запроса HEAD может получить некоторые базовые данные без фактической обработки данных ответа или необходимости использования большой пропускной способности для отправки ответа.
Заключение
Многим Ajax- и веб-программистам материал, представленный в этой статье, может показаться слишком сложным. Какова ценность генерации запроса HEAD? Когда вам нужно явно обрабатывать коды состояния перенаправления в JavaScript? Это хорошие вопросы; для простых приложений ответ таков: ценность этих передовых методов не очень велика.
Однако Интернет больше не является местом, где вам нужно просто внедрять простые приложения; пользователи стали более продвинутыми, клиенты ожидают большей стабильности, более сложных отчетов об ошибках, и если приложение не работает в 1% случаев, тогда менеджер может это сделать. быть уволенным за это.
Поэтому ваша работа не может ограничиваться простыми приложениями, а требует более глубокого понимания XMLHttpRequest.
· Если вы умеете думать о различных состояниях готовности и понимать, чем эти состояния готовности различаются в разных браузерах, вы можете быстро отладить свое приложение. Вы даже можете разработать некоторые творческие функции на основе состояния готовности и сообщать о запрошенном статусе пользователям и клиентам.
· Если вы хотите контролировать коды состояния, вы можете настроить свое приложение для обработки ошибок сценария, неожиданных ответов и крайних случаев. В результате получается приложение, которое работает корректно всегда, а не только тогда, когда все в порядке.
· Добавьте возможность генерировать запросы HEAD, проверять, существует ли URL-адрес, и подтверждать, был ли файл изменен, чтобы гарантировать, что пользователи могут получать действительные страницы и что информация, которую видят пользователи, является самой последней (что наиболее важно) удивляет их. насколько надежным и универсальным является это приложение.
Цель этой статьи — не придать вашему приложению причудливый вид, а помочь вам убрать желтый прожектор и подчеркнуть красоту текста или сделать его более похожим на рабочий стол. Хотя все это особенности Ajax (которые будут рассмотрены в следующих нескольких статьях), они напоминают слой сливок на торте. Если вы сможете использовать Ajax для создания прочной основы, позволяющей вашему приложению хорошо справляться с ошибками и проблемами, пользователи вернутся на ваш сайт и в приложение. В следующей статье мы добавим эту интуитивную технику, которая заставит ваших клиентов дрожать от волнения. (Серьезно, вы же не хотите пропустить следующую статью!)