Главная Обратная связь

Дисциплины:

Архитектура (936)
Биология (6393)
География (744)
История (25)
Компьютеры (1497)
Кулинария (2184)
Культура (3938)
Литература (5778)
Математика (5918)
Медицина (9278)
Механика (2776)
Образование (13883)
Политика (26404)
Правоведение (321)
Психология (56518)
Религия (1833)
Социология (23400)
Спорт (2350)
Строительство (17942)
Технология (5741)
Транспорт (14634)
Физика (1043)
Философия (440)
Финансы (17336)
Химия (4931)
Экология (6055)
Экономика (9200)
Электроника (7621)






Проблема с кешированием в Microsoft Internet Explorer



Internet Explorer кеширует GET-запросы. Одним из решений является использование метода POST, который никогда не кешируется; однако он предназначен для других операций. Другим решением является использование метода запроса GET, включающего уникальную строку запроса с каждым вызовом, как показано на примере ниже.

req.open("GET", "xmlprovider.php?hash=" + Math.random());

Следует помнить, что такой способ сильно забивает кеш. Лучше воспользоваться установкой заголовка Expires на прошедшую дату в вашем скрипте, который генерирует содержимое XML. В PHP это будет так:

header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");

// disable IE caching

header("Last-Modified: " . gmdate( "D, d M Y H:i:s") . " GMT");

header("Cache-Control: no-cache, must-revalidate");

header("Pragma: no-cache");

В сервлетах Java это будет так:

response.setHeader("Pragma", "no-cache");

response.setHeader("Cache-Control", "must-revalidate");

response.setHeader("Cache-Control", "no-cache");

response.setHeader("Cache-Control", "no-store");

response.setDateHeader("Expires", 0);

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

req.open("GET", "xmlprovider.php");

req.setRequestHeader("If-Modified-Since", "Sat, 1 Jan 2000 00:00:00 GMT");

req.send(null);

Важно заметить, что все эти методики должны использоваться в случае, когда кеширование мешает. В основном же лучше получить преимущества в скорости при кешировании.

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

<form action="traditional_action.php" method="post"

onsubmit="perform_ajax_action(); return false;">

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

Вместо использования явного вызова return false в обработчике onsubmit, мы можем проверить есть ли необходимые для Ajax объекты, в вызываемой функции, и выполнить код Ajax если он поддерживается или передать управление форме если нет. Проверим, существует ли функция createAjaxRequest создающая соответствующий браузеру объект XMLHttpRequest.



var request; // our request object

function perform_ajax_action(){

if (!request = createAjaxRequest()){

// попытка использовать Ajax не удалась,

//подтверждаем форму

return true;

}

// нормальная обработка с помощью Ajax

//...

return false; // не подтверждать форму

}

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

<form action="traditional_action.php" method="post"

onsubmit="return perform_ajax_action();">

Если все пройдет хорошо, будет выполнен код Ajax, а подтверждение формы пропущено. При наличии проблем с поддержкой Ajax, форма будет подтверждена, и пользователь сможет продолжить работу обычным образом.

Информируйте пользователя

Сначала нам нужно добавить сообщения об ошибках, о которых не может сообщить браузер. О каких ошибках мы должны сообщить пользователю? Для начала это ошибки соединения. Если запрос не удался, мы сможем получить код ошибки с помощью XMLHttpRequest и вывести соответствующее сообщение. Здесь приведен отрывок функции, которая обрабатывает событие onreadystatechange, объекта request класса XMLHttpRequest.

if (request.readyState == 4){// 4(complete) запрос выполнен

if (request.status == 200){

// HTTP OK, продолжаем нормальную обработку Ajax

//...

}else{

// что-то пошло не так, сообщаем об ошибке

error("HTTP " + request.status +

". Произошла ошибка: " + request.statusText);

}

}

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



Подготовьте запасной план

Главное правило создания клиентских скриптов, не забывать о пользователях, у которых они отключены. В случае использования Ajax это сделать довольно просто с помощью использования «захвата» ссылки или формы.

<form action="traditional_action.php" method="post"

onsubmit="perform_ajax_action(); return false;">

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

Мы можем пойти дальше и проверить поддерживает ли браузер объект XMLHttpRequest. Вместо использования явного вызова return false в обработчике onsubmit, мы можем проверить есть ли необходимые для Ajax объекты, в вызываемой функции, и выполнить код Ajax если он поддерживается или передать управление форме если нет. Проверим, существует ли функция createAjaxRequest создающая соответствующий браузеру объект XMLHttpRequest.

var request; // our request object

function perform_ajax_action(){

if (!request = createAjaxRequest()){

// попытка использовать Ajax не удалась,

//подтверждаем форму

return true;

}

// нормальная обработка с помощью Ajax

//...

return false; // не подтверждать форму

}

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

<form action="traditional_action.php" method="post"

onsubmit="return perform_ajax_action();">

Если все пройдет хорошо, будет выполнен код Ajax, а подтверждение формы пропущено. При наличии проблем с поддержкой Ajax, форма будет подтверждена, и пользователь сможет продолжить работу обычным образом.

Cookies

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

Используя cookie, можно эмулировать сессию по HTTP протоколу. Коротко принцип эмуляции сессии таков: на первом запросе выдается соотвествующее значение cookie, а при каждом последующем запросе это значение читается из переменной окружения HTTP_COOKIE и обрабатывается.

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

Cookie - это небольшая порция текстовой информации, которую сервер передает браузеру. Браузер будет хранить эту информацию и передавать ее серверу с каждым запросом как часть HTTP заголовка. Одни значения cookie могут храниться только в течение одной сессии, они удаляются после закрытия броузера. Другие, установленные на некоторый период времени, записываются в файл. Обычно этот файл называется 'cookies.txt' и лежит в рабочей директории установленного на компьютер браузера.

Сами по себе cookies не могут делать ничего, это только лишь некоторая текстовая информация. Однако сервер может считывать содержащуюся в cookies информацию и на основании ее анализа совершать те или иные действия. Например, в случае авторизованного доступа к чему либо через WWW в cookies сохраняется login и password в течение сессии, что позволяет пользователю не вводить их снова при запросах каждого документа, защищенного паролем.

Еще одна распространенная область использования cookies - при настройке индивидуального профиля каждого зарегистрированного пользователя.

И, наконец, самая последняя область - использование механизма cookie в рекламном бизнесе на Интернет. Еще год назад реклама в Интернет за деньги была довольно экзотической услугой, а сейчас этот бизнес уже устоялся и стремительно развивается. Однако рекламодатели начинают предъявлять более жесткие условия к оценке эффективности своих расходов. Cookie используются для таргетинга рекламы (определения целевой аудитории, например, по географическому положению пользователей), отслеживания интересов пользователей, учета количества показов и проходов сквозь баннеры.

Работа с cookie

Теперь, когда с принципами действия и областями применения cookie все более или менее понятно, можно приступить к изучению формата и синтаксиса, а также способов задания значений cookie.

Формат и синтаксис cookie

Предлагаемое мной в этой статье описание формата и синтаксиса cookie является вольным пересказом изначальной спецификации Netscape Communications "Persistent Client State HTTP Cookies". В настоящий момент идет разработка более строгой спецификации для cookie. Итак, cookie является частью HTTP заголовка. Полное описание поля Set-Cookie HTTP заголовка:

Set-Cookie: NAME=VALUE; expires=DATE; path=PATH; domain=DOMAIN_NAME; secure

Минимальное описание поля Set-Cookie HTTP заголовка: Set-Cookie: NAME=VALUE;

NAME=VALUE - строка символов, исключая перевод строки, запятые и пробелы. NAME-имя cookie, VALUE - значение. Не допускается использование двоеточия, запятой и пробела.

expires=DATE - время хранения cookie, т.е. вместо DATE должна стоять дата в формате "expires=Monday, DD-Mon-YYYY HH:MM:SS GMT", после которой истекает время хранения cookie. Если этот атрибут не указан, то cookie хранится в течение одного сеанса, до закрытия броузера.

domain=DOMAIN_NAME - домен, для которого значение cookie действительно. Например, "domain=cit-forum.com". В этом случае значение cookie будет действительно и для домена cit-forum.com, и для www.cit-forum.com. Но не радуйтесь, указания двух последних периодов доменных имен хватает только для доменов иерархии "COM", "EDU", "NET", "ORG", "GOV", "MIL" и "INT". Для обсуждаемых сейчас новых семи доменов первого уровня ("FIRM", "SHOP", "WEB", "ARTS", "REC", "INFO", "NOM"), вероятно, это условие сохранится. Для доменов иерархии "RU", например, придется указывать три периода.

Если этот атрибут опущен, то по умолчанию используется доменное имя сервера, на котором было задано значение cookie.

path=PATH - этот атрибут устанавливает подмножество документов, для которых действительно значение cookie. Например, указание "path=/win" приведет к тому, что значение cookie будет действительно для множества документов в директории /win/, в директории /wings/ и файлов в текущей директории с именами типа wind.html и windows.shtml. Для того, чтобы cookie отсылались при каждом запросе к серверу, необходимо указать корневой каталог сервера, например, "path=/".

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

secure - если стоит этот маркер, то информация cookie пересылается только через HTTPS (HTTP с использованием SSL - Secure Socket Level), в защищенном режиме. Если этот маркер не указан, то информация пересылается обычным способом.

Синтаксис HTTP заголовка для поля Cookie

Когда запрашивается документ с HTTP сервера, браузер проверяет свои cookie на предмет соответствия домену сервера и прочей информации. В случае, если найдены удовлетворяющие всем условиям значения cookie, броузер посылает их в серверу в виде пары имя/значение:

Cookie: NAME1=OPAQUE_STRING1; NAME2=OPAQUE_STRING2 ...

Дополнительные сведения

Одновременно можно задавать несколько значений cookie.

В случае, если cookie принимает новое значение при имеющемся уже в браузере cookie с совпадающими параметрами NAME, domain и path, то старое значение заменяется новым. В остальных случаях новые значения cookie добавляются к старым.

Использование expires не гарантирует сохранность cookie в течение заданного периода времени, поскольку клиент (браузер) может удалить запись из-за нехватки выделенного места или каких-либо других причин.

Клиент (браузер) имеет следующие ограничения для cookies:

· всего может храниться до 300 значений cookies

· каждый cookie не может превышать 4Кбайт

· с одного сервера или домена может храниться до 20 значений cookie

Если ограничение 300 или 20 превышается, то удаляется первая по времени запись. При превышении лимита объема в 4Кбайт корректность значения cookie страдает - отрезается кусок записи (с начала этой записи) равный превышению объема.

В случае кэширования документов, например, proxy-сервером, поле Set-cookie HTTP заголовка никогда не кэшируется.

Если proxy-сервер принимает ответ, содержащий поле Set-cookie в заголовке, предполагается, что поле доходит до клиента вне зависимости от кода возврата 304 (Not Modified) или 200 (OK). Соответственно, если клиентский запрос содержит в заголовке Cookie, то он должен дойти до сервера, даже если жестко установлен параметр If-modified-since.

Ниже приведено несколько примеров, иллюстрирующих использование cookies

Пример 1. Управление подмножеством документов, для которых действительны значения cookie, и их сроком годности

Браузер запрашивает документ и принимает от сервера в ответ:

Set-Cookie: CUSTOMER=WILE_E_COYOTE; path=/; expires=Wednesday, 09-Nov-99 23:12:40 GMT

Когда браузер запрашивает URL с путем "/" на этом сервере, он посылает серверу: Cookie: CUSTOMER=WILE_E_COYOTE

Браузер запрашивает документ и принимает от сервера в ответ: Set-Cookie: PART_NUMBER=ROCKET_LAUNCHER_0001; path=/

Когда браузер запрашивает URL с путем "/" на этом сервере, он посылает серверу уже два значения cookie: Cookie: CUSTOMER=WILE_E_COYOTE; PART_NUMBER=ROCKET_LAUNCHER_0001

Сервер установил еще одно значение cookie, на этот раз с другой областью действия: Set-Cookie: SHIPPING=FEDEX; path=/foo

Теперь браузер, запрашивая URL с путем "/" на этом сервере, посылает лишь два значения cookie: Cookie: CUSTOMER=WILE_E_COYOTE; PART_NUMBER=ROCKET_LAUNCHER_0001

и лишь при запросе браузером документов с путем "/foo" на этом сервере посылаются все три значения cookie: Cookie: CUSTOMER=WILE_E_COYOTE; PART_NUMBER=ROCKET_LAUNCHER_0001; SHIPPING=FEDEX

Комментарий: после закрытия браузера в файле 'cookies.txt' останется только одно значение cookie:

CUSTOMER=WILE_E_COYOTE

поскольку только для него установлен срок годности - 9 ноября 1999 года. Все остальные значения не будут сохранены.

Пример 2. Значения cookie с одинаковыми именами, но разными параметрами

Браузер запрашивает документ и принимает ответ от сервера:

Set-Cookie: PART_NUMBER=ROCKET_LAUNCHER_0001; path=/

Когда браузер запрашивает URL с путем "/" на этом сервере, он посылает значение: Cookie: PART_NUMBER=ROCKET_LAUNCHER_0001

Во второй раз, запрашивая документ, браузер принимает от сервера значение cookie с другой областью действия: Set-Cookie: PART_NUMBER=RIDING_ROCKET_0023; path=/ammo

Когда браузер запрашивает URL с путем "/ammo" на этом сервере, он посылает значение: Cookie: PART_NUMBER=RIDING_ROCKET_0023; PART_NUMBER=ROCKET_LAUNCHER_0001

Комментарий: здесь мы имеем две пары имя/значение с одинаковым именем "PART_NUMBER". При закрытии браузера ни одно из этих значений не сохранится, поскольку не задан параметр expires.


Эта страница нарушает авторские права

allrefrs.ru - 2019 год. Все права принадлежат их авторам!