Jaki jest najlepszy sposób postępowania z pamięcią podręczną i przyciskiem powrotu do przeglądarki?

Question

Jaki jest najlepszy sposób obsługi użytkownika powracającego do strony, która zawierała elementy w pamięci podręcznej w aplikacji asp.net? Czy istnieje dobry sposób na przechwycenie przycisku wstecz (zdarzenia?) I obsługiwanie pamięci podręcznej w ten sposób?

Answer 1

można spróbować użyć HttpResponse.Cache property jeśli to pomoże:

Response.Cache.SetExpires(DateTime.Now.AddSeconds(60)); 
Response.Cache.SetCacheability(HttpCacheability.Public); 
Response.Cache.SetValidUntilExpires(false); 
Response.Cache.VaryByParams["Category"] = true; 

if (Response.Cache.VaryByParams["Category"]) 
{ 
    //... 
} 

a może mógłby zablokować buforowania strony łącznie z HttpResponse.CacheControl, ale jego została zastąpiona nieruchomości Cache powyżej:

Response.CacheControl = "No-Cache"; 

Edit: ALBO można naprawdę go nuts i zrobić to ręcznie:

Response.ClearHeaders(); 
Response.AppendHeader("Cache-Control", "no-cache"); //HTTP 1.1 
Response.AppendHeader("Cache-Control", "private"); // HTTP 1.1 
Response.AppendHeader("Cache-Control", "no-store"); // HTTP 1.1 
Response.AppendHeader("Cache-Control", "must-revalidate"); // HTTP 1.1 
Response.AppendHeader("Cache-Control", "max-stale=0"); // HTTP 1.1 
Response.AppendHeader("Cache-Control", "post-check=0"); // HTTP 1.1 
Response.AppendHeader("Cache-Control", "pre-check=0"); // HTTP 1.1 
Response.AppendHeader("Pragma", "no-cache"); // HTTP 1.1 
Response.AppendHeader("Keep-Alive", "timeout=3, max=993"); // HTTP 1.1 
Response.AppendHeader("Expires", "Mon, 26 Jul 1997 05:00:00 GMT"); // HTTP 1.1 

Answer 2

Najlepszym sposobem radzenia sobie z tym jest prawdopodobnie umieszczenie dyrektywy bez pamięci podręcznej na stronach ASP.NET (lub stronie wzorcowej, jeśli jest używana). Nie sądzę, aby można było sobie z tym poradzić bezpośrednio w kodzie ASP.NET (ponieważ decyzja o pamięci podręcznej dzieje się na kliencie).

Co do MVC, nie wiem, jak by to osiągnąć (zakładając, że różni się od ASP.NET opartego na Web Forms); Nie użyłem tego.

Answer 3

O ile wiem (a przynajmniej nie czytać) jest jego najlepiej nie próbować działać w odpowiedzi na zdarzenia użytkownika, ale raczej myśleć „na stronie” ..

Architect aplikacja tak nie robi Troszcz się, jeśli przycisk wstecz zostanie naciśnięty. Po prostu sobie z tym poradzi .. Może to oznaczać trochę dodatkowej pracy z punktu widzenia rozwoju, ale ogólnie sprawi, że aplikacja będzie dużo bardziej niezawodna.

Tzn. jeśli w kroku 3 zostaną wykonane niektóre dane, użytkownik kliknie z powrotem (do kroku 2) i kliknie ponownie ponownie, a następnie aplikacja sprawdzi, czy zmiany zostały wprowadzone. Lub najlepiej, nie robi żadnych twardych zmian do momentu, gdy użytkownik kliknie "OK" na końcu. W ten sposób wszystkie zmiany są przechowywane i można ponownie wypełnić formularz na podstawie wcześniej wprowadzonych wartości podczas ładowania, za każdym razem ..

Mam nadzieję, że ma to sens:)

Answer 4

RFC 2616 §13.13 mówi, że Historia i cache są różne rzeczy. Nie powinno być absolutnie żadnego sposobu, aby pamięć podręczna wpływała na przycisk Wstecz.

Jeśli jakakolwiek kombinacja nagłówków HTTP wpływa na przycisk Wstecz, jest to błąd w przeglądarce ... z jednym wyjątkiem.

W HTTP S przeglądarki interpretują Cache-control: must-revalidate jako żądanie odświeżania stron, gdy używany jest przycisk Wstecz (Mozilla nazywa to "trybem głupiego banku"). To nie jest obsługiwane w zwykłym HTTP.

Answer 5

Poniższy kod pracował dla mnie w IE9 +, FF21 i najnowsze Chrome:

Response.Cache.SetCacheability(HttpCacheability.NoCache | HttpCacheability.Private); 
Response.Cache.AppendCacheExtension("must-revalidate"); 
Response.Cache.AppendCacheExtension("max-age=0"); 
Response.Cache.SetNoStore(); 

Możesz umieścić to w Page_Load() obsługi zdarzeń w MasterPage tak, że każda strona w aplikacji wymaga podróż w obie strony do serwer po naciśnięciu przycisku Wstecz.