2010-02-11 2 views
2

У меня возникла странная проблема с outputcache. У меня есть несколько пользовательских элементов управления на странице, одним из которых является элемент управления входами. Страница и элемент управления входами НЕ кэшируются, но другие пользовательские элементы управления кэшируются с помощью VaryByParam. Теперь все это работает вместе с кешированием, когда я нажимаю на разные страницы. Но как только я вхожу в систему, другие пользовательские элементы управления на этой странице отображают старые кешированные версии. Если я обновляю страницу, я получаю правильную кешированную версию всех пользовательских элементов управления. Проблема заключается только в том, что происходит обратная передача. По какой-то причине при обратной передаче кэшированная версия не учитывает строку VaryByParam. При поиске в Интернете, я видел аналогичную проблему, заданную на asp.net, в которой был код, объясняющий это.OutputCache возвращает недопустимую версию с PostBack

Зачем возвращать почтовый ящик, чтобы кэш возвращал неверную версию?

Default.aspx 

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="WebApplication1._Default" %> 
<%@ Register src="WebUserControl1.ascx" tagname="WebUserControl1" tagprefix="uc1" %> 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 
<html xmlns="http://www.w3.org/1999/xhtml" > 
<head runat="server"> 
    <title>Untitled Page</title> 
</head> 
<body> 
    <form id="form1" runat="server">  
     <uc1:WebUserControl1 ID="WebUserControl11" runat="server" EnableViewState="false" />   
    </form> 
</body> 
</html> 

WebUserControl1.ascx 

<%@ Control Language="C#" AutoEventWireup="true" CodeBehind="WebUserControl1.ascx.cs" Inherits="WebApplication1.WebUserControl1" %> 
<%@ OutputCache Duration="3600" VaryByParam="MenuID" %> 
<asp:LinkButton ID="test" runat="server" Text="PostBack"></asp:LinkButton> 
<br /><br /> 
<a href="Default.aspx?menuid=1">1</a> - <a href="Default.aspx?menuid=2">2</a> - <a href="Default.aspx?menuid=3">3</a> 
<br /><br /> 
MenuID: <%= Request.QueryString["MenuID"] != null ? Request.QueryString["MenuID"].ToString() : "null" %> 

Запустите демоверсию, и вы увидите, что щелчок между страницами получает правильную кешированную версию. Но поиграйте с нажатием на страницу и вызовите обратную передачу, а затем вы увидите, что иногда получаете неверную версию кеша.

ответ

2

Я думаю, что это ошибка в ASP .Net, и до ее разрешения это обходное решение.

Для каждой обратной передачи я хочу новую версию, а не кешированную версию. Но в противном случае я хочу кэшированную версию. Поэтому я могу посмотреть, что это за запрос. Если это «POST», я получу новую версию, если это «GET», я получу версию из кеша. Для этого я настраиваю настройку кэша VaryByCustom на usercontrol. И в моем global.asax сделал это:

public override string GetVaryByCustomString(HttpContext context, string arg) 
{ 
    if (arg.Trim().ToLower() == "getorpost") 
    { 
      //for a POST request (postback) force to return back a non cached output 
      if (context.Request.RequestType.Equals("POST")) 
      { 
       return "post" + DateTime.Now.Ticks; 
      } 
      return "get"; 
    } 
    return base.GetVaryByCustomString(context, arg); 
} 
+0

Это, безусловно, вернет новую версию страницы, если она будет реализована правильно, но, похоже, имеет недостаток в загромождении кеша с неизменными версиями страниц.Можно согласиться с этим недостатком и использовать кратковременную продолжительность кэша в качестве компромисса, но он все еще не самый лучший. – Iucounu

0

От кого-то внутри MS:

Поведение выходного кэша для управления изначально было написано (и до сих пор написано), чтобы ключ от либо коллекции строки запроса или сбор значения формы. Внутренняя логика определяет, какую коллекцию следует искать, исходя из того, является ли запрос GET или POST. Я согласен с тем, что поведение меньше, чем очевидно, но это, по-видимому, было первоначальным намерением управления кэшированием.

Два обходными включить значение строки запроса являются частью решений кэша вывода является:

  1. Зеркальных строки запроса значения в скрытых переменных форм, если это возможно .
  2. В качестве альтернативы используйте обходной путь , который уже обнаружен - который должен использовать VaryByCustom и GetVaryByCustomString. Обычай реализация GetVaryByCustomString может вернуть строки, содержащую одно или несколько значений считанные из Request.QueryString для запросов POST, чтобы получить желаемый эффект .
0

Я согласен с Гарфилдом относительно причины, и думаю, что предложение использовать VaryByCustom - тоже умная идея. Для этого вы можете просто использовать Response.Cache.SetNoServerCaching() в Global.asax, что просто требует обнаружения в Global.asax того, является ли страница обратной или нет. Here - пример кода.

 Смежные вопросы

  • Нет связанных вопросов^_^