как очистить данные кеша при использовании ajax?

Question

Я использую Ajax для получения данных с сервера, как показано ниже, на основе некоторого идентификатора для выполнения функции автоматического предложения.однако, когда я отправляю форму и обновляю базу данных, поле автоматического предложения предполагает, что больше не должно содержать ничего для этого идентификатора, но оно все равно будет извлекать данные из своего кэша.Кто-нибудь знает, как очистить кэш и сделать запрос отправки Ajax для получения последних данных с сервера каждый раз, когда я нажимаю кнопку?Помогите, пожалуйста, я действительно застрял на этой целой неделе и не смог найти решение.

Например: когда поле ID равно 00001, поле автоматического предложения будет 1,2,3.После того, как я отправил форму и обновил базу данных, при повторном поиске 00001 он не должен содержать ничего, кроме того, он все равно кэширует данные как 1,2,3 в поле предложения ...

if (window.XMLHttpRequest)
{// code for IE7+, Firefox, Chrome, Opera, Safari
 xmlhttp=new XMLHttpRequest();
}
else
 {// code for IE6, IE5
xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
}
xmlhttp.onreadystatechange=function()
{
if (xmlhttp.readyState==4 && xmlhttp.status==200)
  {
var data=xmlhttp.responseText;
alert(data);

}
}
xmlhttp.open("GET","gethint.php?q="+str,true);
xmlhttp.send();

Answer 1

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

Чтобы легко избежать этой проблемы, я добавил дополнительный параметр запроса (UID). так:

xmlhttp.open("GET","gethint.php?q="+str+**"?something"=RANDOMGUID**,true);

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

Answer 2

Работает с IE8

xmlHttp.open("GET", URL, true);
xmlHttp.setRequestHeader("Cache-Control", "no-cache");
xmlHttp.setRequestHeader("Pragma", "no-cache");
xmlHttp.setRequestHeader("If-Modified-Since", "Sat, 1 Jan 2000 00:00:00 GMT");

Answer 3

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

x = new XMLHttpRequest();
x.onreadystatechange = function() {
    if (this.readyState == 4 && this.status == 200) {
        //execute the other code or function only when the page is really loaded!
    }
};
x.open("GET", "add your url here", true);
x.send();

Answer 4

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

Во-первых, более сжатая версия в одном длинном абзаце:

Если вы хотите получить согласованное представление для учетной записи, независимо от того, какие кнопки истории назад / вперед, дополнительные вкладки или дополнительные окна (даже с разными IP-адресами / устройствами), вы можете использовать счетчик приращений и сердцебиение (сердцебиение может быть реализовано как XMLHttpRequest send () во время вызова setInterval, настроенный на 2 секунды). Инкремент управляется на сервере. Клиент предоставляет значение счетчика при каждом обращении к серверу. При каждом запросе сервер проверяет значение счетчика, предоставленное клиентом, своим собственным сохраненным значением. Сервер создает следующее значение счетчика, сохраняет его и возвращает это значение счетчика в ответ, чтобы клиент мог использовать его при следующем вызове. Если клиент предоставил ожидаемое значение счетчика, это был «хороший» запрос. Если предоставленное значение отличалось от того, что хранил сервер, вызов клиента был «плохим» запросом. Уважайте добрые просьбы. Сервер может только частично удовлетворить плохие запросы. «Следующий» вызов клиента может быть следующим пульсом или любым другим запросом на эту учетную запись. Несколько клиентских представлений в этой учетной записи могут перекрываться, но по сути только один клиент получит следующий хороший вызов. Все остальные клиенты получат плохие последующие вызовы, потому что значения их счетчиков больше не будут соответствовать тому, что хранит сервер. Если вы используете одно представление учетной записи, каждый вызов к серверу должен быть хорошим вызовом после начала сеанса. [Сеанс может длиться, когда браузер javascript поддерживает значение счетчика, но если вы не используете файлы cookie и т. П., Вы не сможете продлить сеанс, если страница обновлена, поскольку javascript будет повторно инициализирован. Это означает, что каждый первый вызов страницы будет «плохим» вызовом.] Если вы используете историю назад, какую-то другую вкладку или какое-либо другое устройство, вы сможете использовать его, но вы получите как минимум плохой вызов всякий раз, когда Вы переключаетесь с одного на другое. Чтобы ограничить количество таких неудачных вызовов, отключите сердцебиение, когда просмотр браузера неактивен. Обратите внимание, что даже не вводите пульс, если вы не возражаете показывать пользователю возможно устаревшую страницу в течение длительного времени или если конкретная страница вряд ли будет устаревшей (но этот вопрос предполагает, что вы можете получить устаревшие данные в представлении браузера пользователя ).

Давайте добавим больше деталей:

Каждый запрос к серверу с существующей открытой страницы браузера предоставляет значение счетчика. Это может быть, например, во время отправки формы или во время javascript объекта XMLHttpRequest .send ().

Запросы, набранные пользователем из строки URL, могут не содержать значения счетчика. Это и вход в систему можно просто рассматривать как имеющие неверное значение счетчика. Это могут быть примеры «плохих» вызовов, и их следует обрабатывать как можно более изящно, но, как правило, не разрешается обновлять учетную запись, если вам требуется согласованное представление.

В каждом запросе на изменение учетной записи («писатель») должно быть указано ожидаемое значение счетчика (которое может обновляться на сервере, кроме как +1, если у вас есть более сложные потребности, но оно должно быть ожидаемым / уникальным для следующий запрос). На стороне сервера, если значение счетчика является ожидаемым, обработайте переменные запроса в обычном режиме и разрешите доступ для записи. Затем включите в ответ клиенту следующее допустимое значение, которое сервер ожидает для этой переменной (например, cnt ++), и сохраните это значение на стороне сервера (например, обновите значение счетчика в базе данных или в каком-либо другом файле сервера), чтобы сервер будет знать следующее допустимое значение счетчика, ожидаемое при поступлении следующего запроса для этой учетной записи.

Запрос, который представляет собой простое «чтение», обрабатывается так же, как и запрос на запись, за исключением того, что, если это неверный запрос (если счетчик не совпадает), чтение с большей вероятностью может быть безопасно обрабатывается.

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

Клиентский JavaScript будет обновлять значение счетчика при каждом ответе сервера на то, что сервер возвращает, так что это обновленное значение счетчика будет отправлено обратнолюбой следующий вызов (например, на пульсе или любой разговор с сервером).Каждый клиентский запрос всегда будет возвращать правильное следующее значение, но только тот клиент, который первым его использует, будет обрабатываться сервером как нормально.

Другие клиенты (т. Е. Любой клиентский запрос, который не обеспечивает ожидаемоговместо значения счетчика) будет дано безопасное состояние, например, текущее состояние в соответствии с базой данных при игнорировании любых запросов записи / обновления.Сервер может обрабатывать «плохие» клиентские вызовы другими более радикальными способами, например, путем выхода пользователя из системы или чего-то еще, но в первую очередь просто удостовериться в том, чтобы максимально удовлетворить запросы безопасного чтения плохого клиента, не обновляя учетную запись каким-либо образом.

Сердцебиение необходимо только в том случае, если вы хотите получить чистый обзор в короткие сроки.Чтобы облегчить работу сервера, вы можете сделать так, чтобы сердцебиение было простым пингом (посылая значение счетчика).Если вас признают хорошим клиентом, вы можете быть готовы к этому сердцебиению.Однако, если вы были плохим клиентом, то сервер может вернуть хорошую свежую информацию, которая может быть использована javascript в коде пульса для обновления GUI.Сердцебиение может относиться к другой странице php-сервера или главной странице, но если она отличается, убедитесь, что страница получает согласованное представление переменной счетчика, сохраненной на сервере (например, используйте базу данных).

Другая функция, которую вы можете реализовать дляУчетная запись имеет статус «активный / неактивный». Клиент будет неактивен, если положение мыши не изменялось в течение нескольких секунд или минут (и в течение этого времени не было введено ни одной клавиши или другого пользовательского ввода). Сердцебиение может деактивироваться само (clearInterval)когда клиент неактивен. При каждом вводе пользователя проверьте, остановлено ли сердцебиение и, если это так, перезапустите его. Перезапуск сердцебиения также означает, что пользователь переходит с неактивного на активный.Когда вы снова станете активным, вы можете делать такие вещи, как выход пользователя из системы, если он был неактивен в течение длительного времени и т. Д. Или просто ничего нового, кроме перезапуска пульса. [Помните, что ответ на пульс может указывать на то, что запрос пульса был"плохой".. что может быть "радикальной" причиной для выхода пользователя из системы, как указано выше.]

Answer 5

Проще всего использовать jQuery # ajax и отключить кеширование.

jQuery добавит суффикс параметра ?somenumber к вашему вызову ajax, которого достаточно, чтобы убедить браузер не использовать кэшированные данные

Я однажды сталкивался с этим. Вот ответ, который я получил: Почему jQuery.ajax () добавляет параметр в URL? .

---

Вы можете сделать то же самое и вручную, но вам придется проверить, все ли в нем добавление параметра.

Answer 6

вы можете использовать http заголовки для предотвращения кэширования ответа:

Cache-Control: no-cache
Expires: Mon, 24 Oct 2005 16:13:22 GMT

Другим вариантом является добавление в URL другого параметра, который меняется каждый раз (например, текущее время в миллисекундах), чтобы браузер задавал другой URL-адрес, и кэш не использовался.