Недавно мы столкнулись с интересной проблемой при запуске веб-сайта, который мы создаем на нашей «машине реплики пользователя», где вы можете получить доступ к приложению через веб-браузер, работающий на Citrix.
Проблема, с которой мы столкнулись, заключалась в том, что в результате запроса get после перенаправления, который мы делали с помощью плагина jQuery Form, не удалось правильно обновить фрагмент страницы. Выглядело так, как будто он заменял его оригинальным HTML.
Мы работаем в Internet Explorer 6 на этой машине, но он отлично работал в этом браузере на нескольких наших машинах разработки.
Мы решили временно изменить код, чтобы не получать запрос после публикации, а вместо этого просто возвращать новую страницу прямо из POST. Все обновлено правильно, используя этот подход.
Придумав всевозможные грандиозные теории о том, как проблема каким-то образом связана с тем фактом, что мы работали через Citrix, мы в некоторой степени пришли к некоторому руководству во внутреннем списке рассылки Иана Робинсона о том, что страница, вероятно, только что кэшировалась, либо WinINet, либо корпоративным прокси, потому что мы не поместили директиву no-store в заголовки ответа.
нет-магазин
Цель директивы no-store — предотвратить
непреднамеренный выпуск или сохранение конфиденциальной информации (
например, на лентах резервных копий). Директива no-store применяется ко
всему сообщению и МОЖЕТ быть отправлена либо в ответе, либо в
запросе. При отправке в запросе кеш НЕ ДОЛЖЕН хранить какую-либо часть
этого запроса или любой ответ на него. Если отправлено в ответе,
кеш НЕ ДОЛЖЕН хранить какую-либо часть этого ответа или
запроса, который его вызвал. Эта директива применяется как к не
совместно используемым, так и совместно используемым кэшам. «НЕ ДОЛЖЕН хранить» в этом контексте означает,
что кэш НЕ ДОЛЖЕН преднамеренно хранить информацию в
энергонезависимом хранилище и ДОЛЖЕН предпринять все возможное для
как
можно быстрее удалить информацию из энергозависимого хранилища после ее пересылки.Даже когда эта директива связана с ответом, пользователи
могут явно хранить такой ответ вне системы кэширования
(например, с помощью диалога «Сохранить как»). Буферы истории МОГУТ хранить
такие ответы как часть их нормальной работы.
JKG опубликовал некоторый код, определяющий атрибут, который мы можем поместить в действия, которые мы не хотим кэшировать в приложении ASP.NET MVC:
public class NoCache : ActionFilterAttribute, IActionFilter
{
public override void OnResultExecuting(ResultExecutingContext filterContext)
{
filterContext.HttpContext.Response.Cache.SetExpires(DateTime.UtcNow.AddDays(-1));
filterContext.HttpContext.Response.Cache.SetValidUntilExpires(false);
filterContext.HttpContext.Response.Cache.SetRevalidation(HttpCacheRevalidation.AllCaches);
filterContext.HttpContext.Response.Cache.SetCacheability(HttpCacheability.NoCache);
filterContext.HttpContext.Response.Cache.SetNoStore();
base.OnResultExecuting(filterContext);
}
public override void OnResultExecuted(ResultExecutedContext filterContext)
{
base.OnResultExecuted(filterContext);
}
}
Мы вставили этот код, и страница начала правильно обновляться.
Крис Лейшман отметил, что другим подходом будет использование « ETags » в заголовке ответа, чтобы страница была получена с сервера, только если она действительно изменилась.
В любом случае нам показалось забавным то, что мы автоматически предполагали, что что-то сложное идет не так, когда на самом деле это было что-то кроме!