Проблема с кэшированием

Question

У меня есть страницы ASPX, но все содержимое генерируется руками (да, я знаю, что мне нужно сделать обработчик, у меня есть еще один вопрос)

Я хочу кэш вывода в браузере клиента. Проблема в том, что он кэшируется только для одного запроса.

 public static void ProceedCaching(string etag, string lastModify, string response, HttpResponse Response, 
             HttpRequest Request) 
    { 
     Response.AddHeader("ETag", "\"" + etag + "\""); 
     Response.AddHeader("Last-Modified", lastModify); 
     Response.AppendHeader("Cache-Control", "Public"); 
     Response.AppendHeader("Expires", 
           DateTime.Now.AddMinutes(1).ToUniversalTime().ToString("r",DateTimeFormatInfo.InvariantInfo)); 

     string ifModified = Request.Headers["If-Modified-Since"]; 

     if (!string.IsNullOrEmpty(ifModified)) 
     { 
      if (ifModified.Contains(";")) 
       ifModified = ifModified.Remove(ifModified.IndexOf(';')); 
     } 

     string incomingEtag = Request.Headers["If-None-Match"]; 

     if (String.Compare(incomingEtag, etag) == 0 || string.Compare(ifModified, lastModify) == 0) 
     { 
      Response.StatusCode = 304; 
      Response.End(); 
     } 

     Response.Write(response); 
     Response.End(); 
    } 

Становится претати грязным. Как я уже говорил, он кэшируется только один раз. После приема HTTP 304 браузер отправит чистый запрос без кэширования информации (etag, lastmodified). Есть идеи?

Answer 1

этот ответ here

Вообще говоря, это самые общие правила, которые следуют (не волнуйтесь, если вы не понимаете, детали, это будет объяснено ниже):

1. Если заголовки ответа сообщают кешу , чтобы он не сохранял его, он не будет.
2. Если запрос аутентифицирован или защищен, он не будет кэшироваться.
3. Если нет валидатора (ETag или Last-Modified заголовка) присутствует на ответ, и он не имеет какую-либо конкретные свежести информации, она будет считается некэшируемыми.
4. кэшированное представление считается свежим (то есть, в состоянии быть отправлен клиенту без проверки с сервером происхождения), если:
   • Он имеет истечение время или другой заголовок возрастного контроля установлен, и все еще находится в пределах свежего периода.
   • Если кеш браузера уже видел это представление, а был установлен для проверки после сеанса.
   • Если прокси-кэш недавно видел представление, а он был изменен относительно давно. Свежие представления подаются непосредственно из кеша, без с сервером происхождения.
5. Если представление несвежее, сервер происхождения будет предложен проверить его, или сказать кэш ли копия, что у него есть это еще хорошо.

И Microsoft имеет хорошую статью, если вы не хотите ее кэшировать.

Answer 2

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

Firefox 3 dosnt даже потрудился попасть на сервер после того, как он получил первые 304. IE7 продолжает работать, но он правильно отправляет заголовки lastmod/etag и каждый раз получает 304.

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

Чтобы сделать его более чистым, вы можете использовать методы Response.Caching, а не напрямую устанавливать заголовки.